Proposed changes to C* Release Schedule
Hi Dev@ List— TL;DR: I’d love it if we could modify the C* release cycle to include an additional “experimental” release branch that straddles the current major releases that includes somewhat “untested” or “risky” commits that normally would only go into the next major release. Releases based from this branch wouldn’t contain any features that require breaking changes or are considered highly “untested” or “risky” but would include the many other commits that today are considered too unsafe to put into the previous stable branch. This will allow us to run code closer to the current stable release branch when we are unable to move fully to the new major release branch. Also, during the release cycle of the next major release branch the project can get feedback from a subset of the total changes that will ultimately make it into that final new major release. Also — i’m aware that any additional branches/releases will add additional work for any developer that works on C*. It would be great if we could strike a balance that hopefully doesn’t add significant additional merging/rebasing/work for the team... The Longer Story: Last week I had a conversation with a few people regarding a proposed change to the current C* release schedule. Other than an attempt to make Jonathan and Sylvian’s lives more difficult, it would be ideal if we could better sync our internal release schedule with more recent Cassandra releases. The current cycle has resulted in currently “active” branches for 1.2, 2.0, 2.1, and +3.0. Official stable releases are from 2.0, beta’s/RC’s from 2.1, and there is the potential for another out-of-band 1.2/previous stable release build. We would love to always run the current “stable” release in production but generally/historically it takes time and a few minor releases to the current “major” branch stable to get to a state where we can accept for use in production. Additionally, as major releases are currently used to make “breaking” changes that require a more involved and risky upgrade process, it’s a much bigger deal to deploy a new major into production than a release without breaking changes. (upgrade-sstables for example is required when upgrading to a new major release branch. this unavoidable step adds lots of temporary load to the cluster and means deploying/upgrading to major releases tends to be a bit more risky than between minor releases and a more involved/long running process). This means even though there are months worth of stable hard work/awesome improvements in the current “stable” major release branch (today this is 2.0), we end up with an unavoidable and undesired lag in getting more recent C* changes pushed into production. This means we are unable to provide feedback on newer changes sooner to the community, stuck and unable to get even a subset of the awesome changes as we can’t yet take ALL the changes from the new major release branch, and finally if we find an issue in production or want to work on new functionality it would be ideal if we can write it against a release that is closer to the next major release while also providing us a reasonable way to get the feature deployed internally on a branch we are running. Currently, the project generally tends to include all risky/breaking/more “feature” oriented tickets only into the next major release + trunk. However, there is a subset of these changes that are “somewhat” more risky changes but pose little/less/no risk the commit with introduce a regression outside of the scope of the patch/component. Additionally, any changes that depend on other higher risk/breaking commits/changes wouldn’t be candidates for this proposed release branch. In a perfect world we would love to target a new “interim” or “experimental” train of releases which is loosely the most stable current release train but also includes a subset of changes from the next major train. (While we were discussing we thought about possible parallels to the concept of a LTS (Long Term Support) release cycle and what some people have dubbed the “tick-tock” release cycle.) This might look something like 1.2 branch + all moderately-to-“less”-risky/non-breaking commits which currently would only end up in a 2.0 or 2.1 release. (Off the top of my head, immediately bad candidates for this build would be for changes to components such as gossip, streaming, or any patch that changes the storage format etc). This would enable the project to provide builds for more active/risk-adverse users looking for a reasonable way to get more features and changes into production than with today’s release cycle. Additionally, this would hopefully facilitate/increase quicker feedback to the project on a subset of the new major release branch and any bugs found could be reported against an actual reproducible release instead of some custom build with a given number of patches from Jira or git SHAs applied/backported.
Re: Proposed changes to C* Release Schedule
Isn't this how it works now? Aka 2.0 is the "I'm risk averse" stable, and 2.1 is the "I'm living on the edge" stable __ Sent from iPhone > On 17 Jun 2014, at 5:16 pm, Michael Kjellman > wrote: > > Hi Dev@ List— > > TL;DR: > I’d love it if we could modify the C* release cycle to include an additional > “experimental” release branch that straddles the current major releases that > includes somewhat “untested” or “risky” commits that normally would only go > into the next major release. Releases based from this branch wouldn’t contain > any features that require breaking changes or are considered highly > “untested” or “risky” but would include the many other commits that today are > considered too unsafe to put into the previous stable branch. This will allow > us to run code closer to the current stable release branch when we are unable > to move fully to the new major release branch. Also, during the release cycle > of the next major release branch the project can get feedback from a subset > of the total changes that will ultimately make it into that final new major > release. Also — i’m aware that any additional branches/releases will add > additional work for any developer that works on C*. It would be great if we > could strike a balance that hopefully doesn’t add significant additional > merging/rebasing/work for the team... > > The Longer Story: > Last week I had a conversation with a few people regarding a proposed change > to the current C* release schedule. > > Other than an attempt to make Jonathan and Sylvian’s lives more difficult, it > would be ideal if we could better sync our internal release schedule with > more recent Cassandra releases. The current cycle has resulted in currently > “active” branches for 1.2, 2.0, 2.1, and +3.0. Official stable releases are > from 2.0, beta’s/RC’s from 2.1, and there is the potential for another > out-of-band 1.2/previous stable release build. We would love to always run > the current “stable” release in production but generally/historically it > takes time and a few minor releases to the current “major” branch stable to > get to a state where we can accept for use in production. Additionally, as > major releases are currently used to make “breaking” changes that require a > more involved and risky upgrade process, it’s a much bigger deal to deploy a > new major into production than a release without breaking changes. > (upgrade-sstables for example is required when upgrading to a new major > release branch. this unavoidable step adds lots of temporary load to the > cluster and means deploying/upgrading to major releases tends to be a bit > more risky than between minor releases and a more involved/long running > process). This means even though there are months worth of stable hard > work/awesome improvements in the current “stable” major release branch (today > this is 2.0), we end up with an unavoidable and undesired lag in getting more > recent C* changes pushed into production. This means we are unable to provide > feedback on newer changes sooner to the community, stuck and unable to get > even a subset of the awesome changes as we can’t yet take ALL the changes > from the new major release branch, and finally if we find an issue in > production or want to work on new functionality it would be ideal if we can > write it against a release that is closer to the next major release while > also providing us a reasonable way to get the feature deployed internally on > a branch we are running. > > Currently, the project generally tends to include all risky/breaking/more > “feature” oriented tickets only into the next major release + trunk. However, > there is a subset of these changes that are “somewhat” more risky changes but > pose little/less/no risk the commit with introduce a regression outside of > the scope of the patch/component. Additionally, any changes that depend on > other higher risk/breaking commits/changes wouldn’t be candidates for this > proposed release branch. In a perfect world we would love to target a new > “interim” or “experimental” train of releases which is loosely the most > stable current release train but also includes a subset of changes from the > next major train. (While we were discussing we thought about possible > parallels to the concept of a LTS (Long Term Support) release cycle and what > some people have dubbed the “tick-tock” release cycle.) This might look > something like 1.2 branch + all moderately-to-“less”-risky/non-breaking > commits which currently would only end up in a 2.0 or 2.1 release. (Off the > top of my head, immediately bad candidates for this build would be for > changes to components such as gossip, streaming, or any patch that changes > the storage format etc). This would enable the project to provide builds for > more active/risk-adverse users looking for a reasonable way to get more > features and
Re: Proposed changes to C* Release Schedule
No, it generally takes months to reach a minor revision of the current major release to reach a release stable enough for most to use in production even if they “live on the edge". Generally there ends up being a very low number of users who've actively deployed released versions 2.0.0-2.0.5 as they too need to evaluate the build and test it in their QA/Staging environments. There are plenty of changes that went into 2.0 that are less risky that are good changes for the “I’m living on the edge” crowd sans the breaking changes and larger risky factors. (I thought i had made this clear — so I apologize I apparently didn’t). Additionally, the longer we have to deploy releases from a particular branch (while a new “stable" branches matures), the farther that branch deviates from trunk. This makes it very hard for us to target development against, especially as we do everything in our power to avoid any sort of branching or running of a special or non-released build. best, michael > On Jun 17, 2014, at 12:42 AM, Jacob Rhoden wrote: > > Isn't this how it works now? Aka > > 2.0 is the "I'm risk averse" stable, and > 2.1 is the "I'm living on the edge" stable > > __ > Sent from iPhone > >> On 17 Jun 2014, at 5:16 pm, Michael Kjellman >> wrote: >> >> Hi Dev@ List— >> >> TL;DR: >> I’d love it if we could modify the C* release cycle to include an additional >> “experimental” release branch that straddles the current major releases that >> includes somewhat “untested” or “risky” commits that normally would only go >> into the next major release. Releases based from this branch wouldn’t >> contain any features that require breaking changes or are considered highly >> “untested” or “risky” but would include the many other commits that today >> are considered too unsafe to put into the previous stable branch. This will >> allow us to run code closer to the current stable release branch when we are >> unable to move fully to the new major release branch. Also, during the >> release cycle of the next major release branch the project can get feedback >> from a subset of the total changes that will ultimately make it into that >> final new major release. Also — i’m aware that any additional >> branches/releases will add additional work for any developer that works on >> C*. It would be great if we could strike a balance that hopefully doesn’t >> add significant additional merging/rebasing/work for the team... >> >> The Longer Story: >> Last week I had a conversation with a few people regarding a proposed change >> to the current C* release schedule. >> >> Other than an attempt to make Jonathan and Sylvian’s lives more difficult, >> it would be ideal if we could better sync our internal release schedule with >> more recent Cassandra releases. The current cycle has resulted in currently >> “active” branches for 1.2, 2.0, 2.1, and +3.0. Official stable releases are >> from 2.0, beta’s/RC’s from 2.1, and there is the potential for another >> out-of-band 1.2/previous stable release build. We would love to always run >> the current “stable” release in production but generally/historically it >> takes time and a few minor releases to the current “major” branch stable to >> get to a state where we can accept for use in production. Additionally, as >> major releases are currently used to make “breaking” changes that require a >> more involved and risky upgrade process, it’s a much bigger deal to deploy a >> new major into production than a release without breaking changes. >> (upgrade-sstables for example is required when upgrading to a new major >> release branch. this unavoidable step adds lots of temporary load to the >> cluster and means deploying/upgrading to major releases tends to be a bit >> more risky than between minor releases and a more involved/long running >> process). This means even though there are months worth of stable hard >> work/awesome improvements in the current “stable” major release branch >> (today this is 2.0), we end up with an unavoidable and undesired lag in >> getting more recent C* changes pushed into production. This means we are >> unable to provide feedback on newer changes sooner to the community, stuck >> and unable to get even a subset of the awesome changes as we can’t yet take >> ALL the changes from the new major release branch, and finally if we find an >> issue in production or want to work on new functionality it would be ideal >> if we can write it against a release that is closer to the next major >> release while also providing us a reasonable way to get the feature deployed >> internally on a branch we are running. >> >> Currently, the project generally tends to include all risky/breaking/more >> “feature” oriented tickets only into the next major release + trunk. >> However, there is a subset of these changes that are “somewhat” more risky >> changes but pose little/less/no risk the co
How to unit test a new flag in QueryOptions regarding PreparedStatements
I am trying to solve CASSANDRA-7304 by adding a new flag to QueryOptions. I changed the core code and now I want to add a unit test. I followed the logic in TupleTypeTest and CQLTester however in order to use this framework I'd need to change the QueryProcessor.executeOnceInternal() to accept the new flag. I am sure there must be another way to do this, without changing core code only for testing purposes. I thought of invoking ExecuteMessage but that requires invoking also a PreparedMessage and it's a bit complicated for the test I want to perform. I can change the driver code to include the new flag but this seems like a big overhead and I can't use it in unit tests. What would be the best way for unit testing a new flag in QueryOptions, that has to do with PreparedStatements? Oded
Re: CMS GC / fragmentation / memtables etc
The discussion about virtual methods was around a number of considerations,
as there was some work to refactor the hierarchy and introduce more virtual
methods for a single allocator's cell hierarchies. The allocator also does
not determine the total set of possible cell implementations, as in-flight
data always exists as an on-heap buffer for this version of Cassandra, so
your supposition is a bit optimistic I'm afraid. This may change in a
future version, but depends on the zero-copy patch that has, as I
mentioned, been shelved for the moment.
1) offheap_objects refers to the fact that we serialize the whole object
into an offheap region of memory, except for a single object reference to
it for accessing this data; they are still (currently) allocated as regions
of offheap memory, so there should not be fragmentation of the native heap
2) Yes, although obviously they are slightly more experimental so will not
be the default memtable type when 2.1 first drops
3) I doubt there would be much difference in the current implementation for
offheap memtables (possibly for row cache) as we allocate large (1M)
regions of native memory to save space and fragmentation (native
allocations typically have ~16 byte overhead which is significant at the
cell level). Currently we support jemalloc as an alternative allocator, but
I would benchmark this allocator in your environment, as it has very high
deallocation costs in some environments.
Tuning these variables will, as with everything, be highly workload
dependent. A rule of thumb for offheap_objects: heap: 100 bytes per
partition, 20 bytes per cell; offheap: 8 (timestamp) + 8 (overhead) +
{clustering+name+data size} per cell
On a memtable flush you will see information printed about occupancy of
each limit, so you will be able to tune accordingly if your data is
consistent.
On Sun, Jun 15, 2014 at 11:52 PM, graham sanderson wrote:
> Hi Benedict thanks once again for your explanations (hopefully these are
> my last questions!)… I just read
> https://issues.apache.org/jira/browse/CASSANDRA-6694 really quickly, so
> didn’t follow all the discussions…. one thing to note that was argued in
> the middle was about the cost of virtual methods with multiple
> implementations. c2 certainly has fast path for 1, and N known
> implementations where 1 de/re-compile on optimistic assumption failure, or actually when new
> classes appear). AFAIK this is also tracked per call site, and since the
> choice of allocator is static on startup, these calls are actually
> monomorphic and inline-able (note I don’t work on the compilers, nor have I
> looked closely at the code, but this is my understanding). Anyway I don’t
> think this affected your final implementation, but should be how it works
> for hot code.
>
> The questions:
>
> 1) Is it fair to say offheap_objects is similar to offheap_buffers, but
> with the added benefit of being able to store (large numbers of) individual
> objects which weren’t kept in the Regions on heap either, because they
> needed to be tracked as actual objects?
>
> 2) That offheap_objects is probably the way to go.
>
> Is/there or will there be some suggestions on tuning
>
> memtable_heap_space_in_mb;
> memtable_offheap_space_in_mb;
>
> compared to memtable_total_space_in_mb today (note
> memtable_total_space_in_mb is actually what is still in cassandra.yaml)
>
> 3) I saw somewhere some talk of using a different malloc implementation
> for less native heap fragmentation, but can’t find it now - do you have a
> recommendation to use the non-standard (have to install it yourself) one.
>
> Thanks,
>
> Graham.
>
> On Jun 15, 2014, at 2:04 PM, Benedict Elliott Smith <
> belliottsm...@datastax.com> wrote:
>
> The current implementation is slower for a single memtable-only read
> (dependent on workload, but similar ball park to on heap), but can store
> substantially more per memtable under offheap_objects (again dependent on
> workload, but as much as 8x in extreme cases) which means more queries are
> answerable from memtable, and write amplification is reduced accordingly,
> improving write throughput.
> On 15 Jun 2014 13:32, "graham sanderson" wrote:
>
> Hi Benedict,
>
> Ah, my mistake, I had assumed that since the memory backing the off heap
> ByteBuffer Regions was freed on discard, that the Regions would be
> immediately recyclable in the on heap case.
>
> I guess I’ll just configure for one of the off-heap variants when 2.1
> comes out…
>
> Any idea of the performance of offheap_buffers and offheap_objects
> (ignoring GC) compared to heap_buffers? I assume offheap_objects must have
> some benefits but presumably at the cost of fragmentation of the native
> heap… obviously I’ll play with it when it comes out… right now we are
> testing something else, so I don’t have a good environment to try 2.1 - and
> that is always kind of meaningless anyways, since we have many different
> apps using cassandra with different usage patterns, and it is hard to mi
Re: How to unit test a new flag in QueryOptions regarding PreparedStatements
You'd probably have to expose a version of executeOnceInternal that directly expose the QueryOptions, but I don't think it would shock anyone. That said, I'm not entirely convinced that modifying the protocol is the way to go for CASSANDRA-7304, so you might want to start first by explaining what you plan on doing on the ticket so we get some kind of consensus on if and how we want to get this. -- Sylvain On Tue, Jun 17, 2014 at 12:30 PM, Peer, Oded wrote: > I am trying to solve CASSANDRA-7304 by adding a new flag to QueryOptions. > I changed the core code and now I want to add a unit test. > > I followed the logic in TupleTypeTest and CQLTester however in order to > use this framework I'd need to change the > QueryProcessor.executeOnceInternal() to accept the new flag. I am sure > there must be another way to do this, without changing core code only for > testing purposes. > I thought of invoking ExecuteMessage but that requires invoking also a > PreparedMessage and it's a bit complicated for the test I want to perform. > I can change the driver code to include the new flag but this seems like a > big overhead and I can't use it in unit tests. > > What would be the best way for unit testing a new flag in QueryOptions, > that has to do with PreparedStatements? > > Oded >
Re: Proposed changes to C* Release Schedule
Hi Michael, I didn't get to hear the in person conversation so taking a step back. The proposal seems to be in response to a common problem. i.e. I'm on C* version X and I need feature Y which is only available on version Z. Is this correct? The options have been: a) upgrade to version Z or b) fork C* and backport. Coming my my previous job where I ran a prod C* cluster I felt this and I expect many others do too. We did have to fork and backport patches we needed and it was hard. This is specific to features and not bugs, since bugs are fixed in all versions affected. -Jake On Tue, Jun 17, 2014 at 3:16 AM, Michael Kjellman < mkjell...@internalcircle.com> wrote: > Hi Dev@ List— > > TL;DR: > I’d love it if we could modify the C* release cycle to include an > additional “experimental” release branch that straddles the current major > releases that includes somewhat “untested” or “risky” commits that normally > would only go into the next major release. Releases based from this branch > wouldn’t contain any features that require breaking changes or are > considered highly “untested” or “risky” but would include the many other > commits that today are considered too unsafe to put into the previous > stable branch. This will allow us to run code closer to the current stable > release branch when we are unable to move fully to the new major release > branch. Also, during the release cycle of the next major release branch the > project can get feedback from a subset of the total changes that will > ultimately make it into that final new major release. Also — i’m aware that > any additional branches/releases will add additional work for any developer > that works on C*. It would be great if we could strike a balance that > hopefully doesn’t add significant additional merging/rebasing/work for the > team... > > The Longer Story: > Last week I had a conversation with a few people regarding a proposed > change to the current C* release schedule. > > Other than an attempt to make Jonathan and Sylvian’s lives more difficult, > it would be ideal if we could better sync our internal release schedule > with more recent Cassandra releases. The current cycle has resulted in > currently “active” branches for 1.2, 2.0, 2.1, and +3.0. Official stable > releases are from 2.0, beta’s/RC’s from 2.1, and there is the potential for > another out-of-band 1.2/previous stable release build. We would love to > always run the current “stable” release in production but > generally/historically it takes time and a few minor releases to the > current “major” branch stable to get to a state where we can accept for use > in production. Additionally, as major releases are currently used to make > “breaking” changes that require a more involved and risky upgrade process, > it’s a much bigger deal to deploy a new major into production than a > release without breaking changes. (upgrade-sstables for example is required > when upgrading to a new major release branch. this unavoidable step adds > lots of temporary load to the cluster and means deploying/upgrading to > major releases tends to be a bit more risky than between minor releases and > a more involved/long running process). This means even though there are > months worth of stable hard work/awesome improvements in the current > “stable” major release branch (today this is 2.0), we end up with an > unavoidable and undesired lag in getting more recent C* changes pushed into > production. This means we are unable to provide feedback on newer changes > sooner to the community, stuck and unable to get even a subset of the > awesome changes as we can’t yet take ALL the changes from the new major > release branch, and finally if we find an issue in production or want to > work on new functionality it would be ideal if we can write it against a > release that is closer to the next major release while also providing us a > reasonable way to get the feature deployed internally on a branch we are > running. > > Currently, the project generally tends to include all risky/breaking/more > “feature” oriented tickets only into the next major release + trunk. > However, there is a subset of these changes that are “somewhat” more risky > changes but pose little/less/no risk the commit with introduce a regression > outside of the scope of the patch/component. Additionally, any changes that > depend on other higher risk/breaking commits/changes wouldn’t be > candidates for this proposed release branch. In a perfect world we would > love to target a new “interim” or “experimental” train of releases which is > loosely the most stable current release train but also includes a subset of > changes from the next major train. (While we were discussing we thought > about possible parallels to the concept of a LTS (Long Term Support) > release cycle and what some people have dubbed the “tick-tock” release > cycle.) This might look something like 1.2 branch + all > moderately-to-“less”-risky/non-breakin
Re: Proposed changes to C* Release Schedule
It's a bit about features - but it's more an attempt to achieve the goals of what might happen with a 4 week release cycle (but that itself -- in practice didn't prove to be valid/reasonable). If something like an executor service for performance is changed (for example) it is definitely a more risky change than what would currently go into 1.2 -- but most likely we would want to get patches like that into a usable build. So I guess: a) reduce code drift between branches we run in production b) get newer "features" into production faster where breaking changes aren't required for the scope of the patch. Additionally - it's also a question of what release we use when we identify an issue we want to work on internally. If we are on 1.2 because we can't yet take ALL of 2.0 - do we now need to target our work against 1.2? I would rather write it against the months worth of changes that have happened since. Finally, it's an attempt to make the internal forking not as common as it might be today. As you said - this is somewhat of a common process. > On Jun 17, 2014, at 8:52 AM, "Jake Luciani" wrote > > Hi Michael, > > I didn't get to hear the in person conversation so taking a step back. > The proposal seems to be in response to a common problem. i.e. I'm on C* > version X and I need feature Y which is only available on version Z. Is > this correct? > > The options have been: a) upgrade to version Z or b) fork C* and backport. > Coming my my previous job where I ran a prod C* cluster I felt this and I > expect many others do too. We did have to fork and backport patches we > needed and it was hard. > > This is specific to features and not bugs, since bugs are fixed in all > versions affected. > > -Jake > > > > > > > On Tue, Jun 17, 2014 at 3:16 AM, Michael Kjellman < > mkjell...@internalcircle.com> wrote: > >> Hi Dev@ List— >> >> TL;DR: >> I’d love it if we could modify the C* release cycle to include an >> additional “experimental” release branch that straddles the current major >> releases that includes somewhat “untested” or “risky” commits that normally >> would only go into the next major release. Releases based from this branch >> wouldn’t contain any features that require breaking changes or are >> considered highly “untested” or “risky” but would include the many other >> commits that today are considered too unsafe to put into the previous >> stable branch. This will allow us to run code closer to the current stable >> release branch when we are unable to move fully to the new major release >> branch. Also, during the release cycle of the next major release branch the >> project can get feedback from a subset of the total changes that will >> ultimately make it into that final new major release. Also — i’m aware that >> any additional branches/releases will add additional work for any developer >> that works on C*. It would be great if we could strike a balance that >> hopefully doesn’t add significant additional merging/rebasing/work for the >> team... >> >> The Longer Story: >> Last week I had a conversation with a few people regarding a proposed >> change to the current C* release schedule. >> >> Other than an attempt to make Jonathan and Sylvian’s lives more difficult, >> it would be ideal if we could better sync our internal release schedule >> with more recent Cassandra releases. The current cycle has resulted in >> currently “active” branches for 1.2, 2.0, 2.1, and +3.0. Official stable >> releases are from 2.0, beta’s/RC’s from 2.1, and there is the potential for >> another out-of-band 1.2/previous stable release build. We would love to >> always run the current “stable” release in production but >> generally/historically it takes time and a few minor releases to the >> current “major” branch stable to get to a state where we can accept for use >> in production. Additionally, as major releases are currently used to make >> “breaking” changes that require a more involved and risky upgrade process, >> it’s a much bigger deal to deploy a new major into production than a >> release without breaking changes. (upgrade-sstables for example is required >> when upgrading to a new major release branch. this unavoidable step adds >> lots of temporary load to the cluster and means deploying/upgrading to >> major releases tends to be a bit more risky than between minor releases and >> a more involved/long running process). This means even though there are >> months worth of stable hard work/awesome improvements in the current >> “stable” major release branch (today this is 2.0), we end up with an >> unavoidable and undesired lag in getting more recent C* changes pushed into >> production. This means we are unable to provide feedback on newer changes >> sooner to the community, stuck and unable to get even a subset of the >> awesome changes as we can’t yet take ALL the changes from the new major >> release branch, and finally if we find an issue in production or want to >>
Re: Proposed changes to C* Release Schedule
I'm not sure many people have the problem you are describing. This is more of a C* developer issue than a C* user issue. Is the below what you are describing we move to?: 1.2 -> 2.0 -> 2.1 -> 3.0 stable 1.2 <- 2.0 <- 2.1 <- 3.0 experimental Specific changes would be backported based on the "less riskyness" of the change which you are assuming will be constant across versions? -Jake On Tue, Jun 17, 2014 at 12:28 PM, Michael Kjellman < mkjell...@internalcircle.com> wrote: > It's a bit about features - but it's more an attempt to achieve the goals > of what might happen with a 4 week release cycle (but that itself -- in > practice didn't prove to be valid/reasonable). > > If something like an executor service for performance is changed (for > example) it is definitely a more risky change than what would currently go > into 1.2 -- but most likely we would want to get patches like that into a > usable build. > > So I guess: a) reduce code drift between branches we run in production b) > get newer "features" into production faster where breaking changes aren't > required for the scope of the patch. > > Additionally - it's also a question of what release we use when we > identify an issue we want to work on internally. If we are on 1.2 because > we can't yet take ALL of 2.0 - do we now need to target our work against > 1.2? I would rather write it against the months worth of changes that have > happened since. > > Finally, it's an attempt to make the internal forking not as common as it > might be today. As you said - this is somewhat of a common process. > > > On Jun 17, 2014, at 8:52 AM, "Jake Luciani" wrote > > > > Hi Michael, > > > > I didn't get to hear the in person conversation so taking a step back. > > The proposal seems to be in response to a common problem. i.e. I'm on > C* > > version X and I need feature Y which is only available on version Z. Is > > this correct? > > > > The options have been: a) upgrade to version Z or b) fork C* and > backport. > > Coming my my previous job where I ran a prod C* cluster I felt this and I > > expect many others do too. We did have to fork and backport patches we > > needed and it was hard. > > > > This is specific to features and not bugs, since bugs are fixed in all > > versions affected. > > > > -Jake > > > > > > > > > > > > > > On Tue, Jun 17, 2014 at 3:16 AM, Michael Kjellman < > > mkjell...@internalcircle.com> wrote: > > > >> Hi Dev@ List— > >> > >> TL;DR: > >> I’d love it if we could modify the C* release cycle to include an > >> additional “experimental” release branch that straddles the current > major > >> releases that includes somewhat “untested” or “risky” commits that > normally > >> would only go into the next major release. Releases based from this > branch > >> wouldn’t contain any features that require breaking changes or are > >> considered highly “untested” or “risky” but would include the many other > >> commits that today are considered too unsafe to put into the previous > >> stable branch. This will allow us to run code closer to the current > stable > >> release branch when we are unable to move fully to the new major release > >> branch. Also, during the release cycle of the next major release branch > the > >> project can get feedback from a subset of the total changes that will > >> ultimately make it into that final new major release. Also — i’m aware > that > >> any additional branches/releases will add additional work for any > developer > >> that works on C*. It would be great if we could strike a balance that > >> hopefully doesn’t add significant additional merging/rebasing/work for > the > >> team... > >> > >> The Longer Story: > >> Last week I had a conversation with a few people regarding a proposed > >> change to the current C* release schedule. > >> > >> Other than an attempt to make Jonathan and Sylvian’s lives more > difficult, > >> it would be ideal if we could better sync our internal release schedule > >> with more recent Cassandra releases. The current cycle has resulted in > >> currently “active” branches for 1.2, 2.0, 2.1, and +3.0. Official stable > >> releases are from 2.0, beta’s/RC’s from 2.1, and there is the potential > for > >> another out-of-band 1.2/previous stable release build. We would love to > >> always run the current “stable” release in production but > >> generally/historically it takes time and a few minor releases to the > >> current “major” branch stable to get to a state where we can accept for > use > >> in production. Additionally, as major releases are currently used to > make > >> “breaking” changes that require a more involved and risky upgrade > process, > >> it’s a much bigger deal to deploy a new major into production than a > >> release without breaking changes. (upgrade-sstables for example is > required > >> when upgrading to a new major release branch. this unavoidable step adds > >> lots of temporary load to the cluster and means deploying/upgrading to > >> major releases
Re: Proposed changes to C* Release Schedule
If that's what we want, merging is going to be much more painful. Currently we merge: 1.2->2.0->2.1->3.0 If we add an experimental branch for each, we still have to merge the stable branch into experiemental: 1-2->1.2ex, 2.0->2.0ex, 2.1->2.1ex, 3.0->3.0ex And then the experimentals into each other: 1.2ex->2.0ex, 2.0ex->2.1ex, 2.1ex->3.0ex That's quite a lot of merging in the end. On Tue, Jun 17, 2014 at 11:51 AM, Jake Luciani wrote: > I'm not sure many people have the problem you are describing. This is more > of a C* developer issue than a C* user issue. > > > Is the below what you are describing we move to?: > > 1.2 -> 2.0 -> 2.1 -> 3.0 stable > 1.2 <- 2.0 <- 2.1 <- 3.0 experimental > > Specific changes would be backported based on the "less riskyness" of the > change which you are assuming will be constant across versions? > > -Jake > > > > > On Tue, Jun 17, 2014 at 12:28 PM, Michael Kjellman < > mkjell...@internalcircle.com> wrote: > > > It's a bit about features - but it's more an attempt to achieve the goals > > of what might happen with a 4 week release cycle (but that itself -- in > > practice didn't prove to be valid/reasonable). > > > > If something like an executor service for performance is changed (for > > example) it is definitely a more risky change than what would currently > go > > into 1.2 -- but most likely we would want to get patches like that into a > > usable build. > > > > So I guess: a) reduce code drift between branches we run in production b) > > get newer "features" into production faster where breaking changes aren't > > required for the scope of the patch. > > > > Additionally - it's also a question of what release we use when we > > identify an issue we want to work on internally. If we are on 1.2 because > > we can't yet take ALL of 2.0 - do we now need to target our work against > > 1.2? I would rather write it against the months worth of changes that > have > > happened since. > > > > Finally, it's an attempt to make the internal forking not as common as it > > might be today. As you said - this is somewhat of a common process. > > > > > On Jun 17, 2014, at 8:52 AM, "Jake Luciani" wrote > > > > > > Hi Michael, > > > > > > I didn't get to hear the in person conversation so taking a step back. > > > The proposal seems to be in response to a common problem. i.e. I'm on > > C* > > > version X and I need feature Y which is only available on version Z. Is > > > this correct? > > > > > > The options have been: a) upgrade to version Z or b) fork C* and > > backport. > > > Coming my my previous job where I ran a prod C* cluster I felt this > and I > > > expect many others do too. We did have to fork and backport patches we > > > needed and it was hard. > > > > > > This is specific to features and not bugs, since bugs are fixed in all > > > versions affected. > > > > > > -Jake > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 17, 2014 at 3:16 AM, Michael Kjellman < > > > mkjell...@internalcircle.com> wrote: > > > > > >> Hi Dev@ List— > > >> > > >> TL;DR: > > >> I’d love it if we could modify the C* release cycle to include an > > >> additional “experimental” release branch that straddles the current > > major > > >> releases that includes somewhat “untested” or “risky” commits that > > normally > > >> would only go into the next major release. Releases based from this > > branch > > >> wouldn’t contain any features that require breaking changes or are > > >> considered highly “untested” or “risky” but would include the many > other > > >> commits that today are considered too unsafe to put into the previous > > >> stable branch. This will allow us to run code closer to the current > > stable > > >> release branch when we are unable to move fully to the new major > release > > >> branch. Also, during the release cycle of the next major release > branch > > the > > >> project can get feedback from a subset of the total changes that will > > >> ultimately make it into that final new major release. Also — i’m aware > > that > > >> any additional branches/releases will add additional work for any > > developer > > >> that works on C*. It would be great if we could strike a balance that > > >> hopefully doesn’t add significant additional merging/rebasing/work for > > the > > >> team... > > >> > > >> The Longer Story: > > >> Last week I had a conversation with a few people regarding a proposed > > >> change to the current C* release schedule. > > >> > > >> Other than an attempt to make Jonathan and Sylvian’s lives more > > difficult, > > >> it would be ideal if we could better sync our internal release > schedule > > >> with more recent Cassandra releases. The current cycle has resulted in > > >> currently “active” branches for 1.2, 2.0, 2.1, and +3.0. Official > stable > > >> releases are from 2.0, beta’s/RC’s from 2.1, and there is the > potential > > for > > >> another out-of-band 1.2/previous stable release build. We would love > to > > >> always run the current “st
Re: Proposed changes to C* Release Schedule
I agree — but there are lots of people though who lag in adoption while waiting for more “risky” or “breaking” changes to shake out/stabilize that want to continue deploying newer fixes. No? > On Jun 17, 2014, at 9:51 AM, Jake Luciani wrote: > > I'm not sure many people have the problem you are describing. This is more > of a C* developer issue than a C* user issue. > > > Is the below what you are describing we move to?: > > 1.2 -> 2.0 -> 2.1 -> 3.0 stable > 1.2 <- 2.0 <- 2.1 <- 3.0 experimental > > Specific changes would be backported based on the "less riskyness" of the > change which you are assuming will be constant across versions? > > -Jake > > > > > On Tue, Jun 17, 2014 at 12:28 PM, Michael Kjellman < > mkjell...@internalcircle.com> wrote: > >> It's a bit about features - but it's more an attempt to achieve the goals >> of what might happen with a 4 week release cycle (but that itself -- in >> practice didn't prove to be valid/reasonable). >> >> If something like an executor service for performance is changed (for >> example) it is definitely a more risky change than what would currently go >> into 1.2 -- but most likely we would want to get patches like that into a >> usable build. >> >> So I guess: a) reduce code drift between branches we run in production b) >> get newer "features" into production faster where breaking changes aren't >> required for the scope of the patch. >> >> Additionally - it's also a question of what release we use when we >> identify an issue we want to work on internally. If we are on 1.2 because >> we can't yet take ALL of 2.0 - do we now need to target our work against >> 1.2? I would rather write it against the months worth of changes that have >> happened since. >> >> Finally, it's an attempt to make the internal forking not as common as it >> might be today. As you said - this is somewhat of a common process. >> >>> On Jun 17, 2014, at 8:52 AM, "Jake Luciani" wrote >>> >>> Hi Michael, >>> >>> I didn't get to hear the in person conversation so taking a step back. >>> The proposal seems to be in response to a common problem. i.e. I'm on >> C* >>> version X and I need feature Y which is only available on version Z. Is >>> this correct? >>> >>> The options have been: a) upgrade to version Z or b) fork C* and >> backport. >>> Coming my my previous job where I ran a prod C* cluster I felt this and I >>> expect many others do too. We did have to fork and backport patches we >>> needed and it was hard. >>> >>> This is specific to features and not bugs, since bugs are fixed in all >>> versions affected. >>> >>> -Jake >>> >>> >>> >>> >>> >>> >>> On Tue, Jun 17, 2014 at 3:16 AM, Michael Kjellman < >>> mkjell...@internalcircle.com> wrote: >>> Hi Dev@ List— TL;DR: I’d love it if we could modify the C* release cycle to include an additional “experimental” release branch that straddles the current >> major releases that includes somewhat “untested” or “risky” commits that >> normally would only go into the next major release. Releases based from this >> branch wouldn’t contain any features that require breaking changes or are considered highly “untested” or “risky” but would include the many other commits that today are considered too unsafe to put into the previous stable branch. This will allow us to run code closer to the current >> stable release branch when we are unable to move fully to the new major release branch. Also, during the release cycle of the next major release branch >> the project can get feedback from a subset of the total changes that will ultimately make it into that final new major release. Also — i’m aware >> that any additional branches/releases will add additional work for any >> developer that works on C*. It would be great if we could strike a balance that hopefully doesn’t add significant additional merging/rebasing/work for >> the team... The Longer Story: Last week I had a conversation with a few people regarding a proposed change to the current C* release schedule. Other than an attempt to make Jonathan and Sylvian’s lives more >> difficult, it would be ideal if we could better sync our internal release schedule with more recent Cassandra releases. The current cycle has resulted in currently “active” branches for 1.2, 2.0, 2.1, and +3.0. Official stable releases are from 2.0, beta’s/RC’s from 2.1, and there is the potential >> for another out-of-band 1.2/previous stable release build. We would love to always run the current “stable” release in production but generally/historically it takes time and a few minor releases to the current “major” branch stable to get to a state where we can accept for >> use in production. Additionally, as major releases are currently used to >> make “breaking” changes that require a more involved and risky upgr
Re: Proposed changes to C* Release Schedule
Totally agree — "Also — i’m aware that any additional branches/releases will add additional work for any developer that works on C*. It would be great if we could strike a balance that hopefully doesn’t add significant additional merging/rebasing/work for the team…” That being said I don’t think i’m alone by identifying the problem. The proposed solution was what we came up with in the hour or so we discussed this in person. How else can you shrink the release schedule without creating another branch? Also — the idea is to only have this branch “active” during the overlap when major release branches need to stabilize. > On Jun 17, 2014, at 10:03 AM, Brandon Williams wrote: > > If that's what we want, merging is going to be much more painful. > Currently we merge: > > 1.2->2.0->2.1->3.0 > > If we add an experimental branch for each, we still have to merge the > stable branch into experiemental: > > 1-2->1.2ex, 2.0->2.0ex, 2.1->2.1ex, 3.0->3.0ex > > And then the experimentals into each other: > > 1.2ex->2.0ex, 2.0ex->2.1ex, 2.1ex->3.0ex > > That's quite a lot of merging in the end. > > > On Tue, Jun 17, 2014 at 11:51 AM, Jake Luciani wrote: > >> I'm not sure many people have the problem you are describing. This is more >> of a C* developer issue than a C* user issue. >> >> >> Is the below what you are describing we move to?: >> >> 1.2 -> 2.0 -> 2.1 -> 3.0 stable >> 1.2 <- 2.0 <- 2.1 <- 3.0 experimental >> >> Specific changes would be backported based on the "less riskyness" of the >> change which you are assuming will be constant across versions? >> >> -Jake >> >> >> >> >> On Tue, Jun 17, 2014 at 12:28 PM, Michael Kjellman < >> mkjell...@internalcircle.com> wrote: >> >>> It's a bit about features - but it's more an attempt to achieve the goals >>> of what might happen with a 4 week release cycle (but that itself -- in >>> practice didn't prove to be valid/reasonable). >>> >>> If something like an executor service for performance is changed (for >>> example) it is definitely a more risky change than what would currently >> go >>> into 1.2 -- but most likely we would want to get patches like that into a >>> usable build. >>> >>> So I guess: a) reduce code drift between branches we run in production b) >>> get newer "features" into production faster where breaking changes aren't >>> required for the scope of the patch. >>> >>> Additionally - it's also a question of what release we use when we >>> identify an issue we want to work on internally. If we are on 1.2 because >>> we can't yet take ALL of 2.0 - do we now need to target our work against >>> 1.2? I would rather write it against the months worth of changes that >> have >>> happened since. >>> >>> Finally, it's an attempt to make the internal forking not as common as it >>> might be today. As you said - this is somewhat of a common process. >>> On Jun 17, 2014, at 8:52 AM, "Jake Luciani" wrote Hi Michael, I didn't get to hear the in person conversation so taking a step back. The proposal seems to be in response to a common problem. i.e. I'm on >>> C* version X and I need feature Y which is only available on version Z. Is this correct? The options have been: a) upgrade to version Z or b) fork C* and >>> backport. Coming my my previous job where I ran a prod C* cluster I felt this >> and I expect many others do too. We did have to fork and backport patches we needed and it was hard. This is specific to features and not bugs, since bugs are fixed in all versions affected. -Jake On Tue, Jun 17, 2014 at 3:16 AM, Michael Kjellman < mkjell...@internalcircle.com> wrote: > Hi Dev@ List— > > TL;DR: > I’d love it if we could modify the C* release cycle to include an > additional “experimental” release branch that straddles the current >>> major > releases that includes somewhat “untested” or “risky” commits that >>> normally > would only go into the next major release. Releases based from this >>> branch > wouldn’t contain any features that require breaking changes or are > considered highly “untested” or “risky” but would include the many >> other > commits that today are considered too unsafe to put into the previous > stable branch. This will allow us to run code closer to the current >>> stable > release branch when we are unable to move fully to the new major >> release > branch. Also, during the release cycle of the next major release >> branch >>> the > project can get feedback from a subset of the total changes that will > ultimately make it into that final new major release. Also — i’m aware >>> that > any additional branches/releases will add additional work for any >>> developer > that works on C*. It would be great if we could strike a balance that > hopefully doesn’t add significant additional merg
Re: Proposed changes to C* Release Schedule
So there are two issues this proposal is trying to address: 1. Shrink the release cycle. 2. Backport things to stable releases. We should discuss these separately since together it's hard to discuss. 1. is less controversial I would think :) On Tue, Jun 17, 2014 at 1:16 PM, Michael Kjellman < mkjell...@internalcircle.com> wrote: > Totally agree — "Also — i’m aware that any additional branches/releases > will add additional work for any developer that works on C*. It would be > great if we could strike a balance that hopefully doesn’t add significant > additional merging/rebasing/work for the team…” > > That being said I don’t think i’m alone by identifying the problem. The > proposed solution was what we came up with in the hour or so we discussed > this in person. How else can you shrink the release schedule without > creating another branch? Also — the idea is to only have this branch > “active” during the overlap when major release branches need to stabilize. > > > On Jun 17, 2014, at 10:03 AM, Brandon Williams wrote: > > > > If that's what we want, merging is going to be much more painful. > > Currently we merge: > > > > 1.2->2.0->2.1->3.0 > > > > If we add an experimental branch for each, we still have to merge the > > stable branch into experiemental: > > > > 1-2->1.2ex, 2.0->2.0ex, 2.1->2.1ex, 3.0->3.0ex > > > > And then the experimentals into each other: > > > > 1.2ex->2.0ex, 2.0ex->2.1ex, 2.1ex->3.0ex > > > > That's quite a lot of merging in the end. > > > > > > On Tue, Jun 17, 2014 at 11:51 AM, Jake Luciani wrote: > > > >> I'm not sure many people have the problem you are describing. This is > more > >> of a C* developer issue than a C* user issue. > >> > >> > >> Is the below what you are describing we move to?: > >> > >> 1.2 -> 2.0 -> 2.1 -> 3.0 stable > >> 1.2 <- 2.0 <- 2.1 <- 3.0 experimental > >> > >> Specific changes would be backported based on the "less riskyness" of > the > >> change which you are assuming will be constant across versions? > >> > >> -Jake > >> > >> > >> > >> > >> On Tue, Jun 17, 2014 at 12:28 PM, Michael Kjellman < > >> mkjell...@internalcircle.com> wrote: > >> > >>> It's a bit about features - but it's more an attempt to achieve the > goals > >>> of what might happen with a 4 week release cycle (but that itself -- in > >>> practice didn't prove to be valid/reasonable). > >>> > >>> If something like an executor service for performance is changed (for > >>> example) it is definitely a more risky change than what would currently > >> go > >>> into 1.2 -- but most likely we would want to get patches like that > into a > >>> usable build. > >>> > >>> So I guess: a) reduce code drift between branches we run in production > b) > >>> get newer "features" into production faster where breaking changes > aren't > >>> required for the scope of the patch. > >>> > >>> Additionally - it's also a question of what release we use when we > >>> identify an issue we want to work on internally. If we are on 1.2 > because > >>> we can't yet take ALL of 2.0 - do we now need to target our work > against > >>> 1.2? I would rather write it against the months worth of changes that > >> have > >>> happened since. > >>> > >>> Finally, it's an attempt to make the internal forking not as common as > it > >>> might be today. As you said - this is somewhat of a common process. > >>> > On Jun 17, 2014, at 8:52 AM, "Jake Luciani" wrote > > Hi Michael, > > I didn't get to hear the in person conversation so taking a step back. > The proposal seems to be in response to a common problem. i.e. I'm > on > >>> C* > version X and I need feature Y which is only available on version Z. > Is > this correct? > > The options have been: a) upgrade to version Z or b) fork C* and > >>> backport. > Coming my my previous job where I ran a prod C* cluster I felt this > >> and I > expect many others do too. We did have to fork and backport patches > we > needed and it was hard. > > This is specific to features and not bugs, since bugs are fixed in all > versions affected. > > -Jake > > > > > > > On Tue, Jun 17, 2014 at 3:16 AM, Michael Kjellman < > mkjell...@internalcircle.com> wrote: > > > Hi Dev@ List— > > > > TL;DR: > > I’d love it if we could modify the C* release cycle to include an > > additional “experimental” release branch that straddles the current > >>> major > > releases that includes somewhat “untested” or “risky” commits that > >>> normally > > would only go into the next major release. Releases based from this > >>> branch > > wouldn’t contain any features that require breaking changes or are > > considered highly “untested” or “risky” but would include the many > >> other > > commits that today are considered too unsafe to put into the previous > > stable branch. This will allow us to run code closer to the current >
Re: Proposed changes to C* Release Schedule
Agreed. But I think shrinking the release cycle naturally will get features into usable releases more quickly solving b as well. :) > On Jun 17, 2014, at 10:28 AM, "Jake Luciani" wrote: > > So there are two issues this proposal is trying to address: > > 1. Shrink the release cycle. > > 2. Backport things to stable releases. > > We should discuss these separately since together it's hard to discuss. > 1. is less controversial I would think :) > > > > > > > On Tue, Jun 17, 2014 at 1:16 PM, Michael Kjellman < > mkjell...@internalcircle.com> wrote: > >> Totally agree — "Also — i’m aware that any additional branches/releases >> will add additional work for any developer that works on C*. It would be >> great if we could strike a balance that hopefully doesn’t add significant >> additional merging/rebasing/work for the team…” >> >> That being said I don’t think i’m alone by identifying the problem. The >> proposed solution was what we came up with in the hour or so we discussed >> this in person. How else can you shrink the release schedule without >> creating another branch? Also — the idea is to only have this branch >> “active” during the overlap when major release branches need to stabilize. >> >>> On Jun 17, 2014, at 10:03 AM, Brandon Williams wrote: >>> >>> If that's what we want, merging is going to be much more painful. >>> Currently we merge: >>> >>> 1.2->2.0->2.1->3.0 >>> >>> If we add an experimental branch for each, we still have to merge the >>> stable branch into experiemental: >>> >>> 1-2->1.2ex, 2.0->2.0ex, 2.1->2.1ex, 3.0->3.0ex >>> >>> And then the experimentals into each other: >>> >>> 1.2ex->2.0ex, 2.0ex->2.1ex, 2.1ex->3.0ex >>> >>> That's quite a lot of merging in the end. >>> >>> On Tue, Jun 17, 2014 at 11:51 AM, Jake Luciani wrote: I'm not sure many people have the problem you are describing. This is >> more of a C* developer issue than a C* user issue. Is the below what you are describing we move to?: 1.2 -> 2.0 -> 2.1 -> 3.0 stable 1.2 <- 2.0 <- 2.1 <- 3.0 experimental Specific changes would be backported based on the "less riskyness" of >> the change which you are assuming will be constant across versions? -Jake On Tue, Jun 17, 2014 at 12:28 PM, Michael Kjellman < mkjell...@internalcircle.com> wrote: > It's a bit about features - but it's more an attempt to achieve the >> goals > of what might happen with a 4 week release cycle (but that itself -- in > practice didn't prove to be valid/reasonable). > > If something like an executor service for performance is changed (for > example) it is definitely a more risky change than what would currently go > into 1.2 -- but most likely we would want to get patches like that >> into a > usable build. > > So I guess: a) reduce code drift between branches we run in production >> b) > get newer "features" into production faster where breaking changes >> aren't > required for the scope of the patch. > > Additionally - it's also a question of what release we use when we > identify an issue we want to work on internally. If we are on 1.2 >> because > we can't yet take ALL of 2.0 - do we now need to target our work >> against > 1.2? I would rather write it against the months worth of changes that have > happened since. > > Finally, it's an attempt to make the internal forking not as common as >> it > might be today. As you said - this is somewhat of a common process. > >> On Jun 17, 2014, at 8:52 AM, "Jake Luciani" wrote >> >> Hi Michael, >> >> I didn't get to hear the in person conversation so taking a step back. >> The proposal seems to be in response to a common problem. i.e. I'm >> on > C* >> version X and I need feature Y which is only available on version Z. >> Is >> this correct? >> >> The options have been: a) upgrade to version Z or b) fork C* and > backport. >> Coming my my previous job where I ran a prod C* cluster I felt this and I >> expect many others do too. We did have to fork and backport patches >> we >> needed and it was hard. >> >> This is specific to features and not bugs, since bugs are fixed in all >> versions affected. >> >> -Jake >> >> >> >> >> >> >> On Tue, Jun 17, 2014 at 3:16 AM, Michael Kjellman < >> mkjell...@internalcircle.com> wrote: >> >>> Hi Dev@ List— >>> >>> TL;DR: >>> I’d love it if we could modify the C* release cycle to include an >>> additional “experimental” release branch that straddles the current > major >>> releases that includes somewhat “untested” or “risky” commits that > normally >>> would only go into the next major release. Releases based from this > branch >>> wouldn’t contain
Re: Proposed changes to C* Release Schedule
FWIW, here's the ubuntu wiki on their release model: https://wiki.ubuntu.com/TimeBasedReleases Short story: they have a feature set for each release, and it must be tested thoroughly before going out the door. Granted, they are shipping an entire OS with 1000s of components that all must work well *together*, but there may be something we can learn from their process - I'm not necessarily recommending we adopt it, but it seems to work for Ubuntu. -Jason On Tue, Jun 17, 2014 at 10:27 AM, Jake Luciani wrote: > So there are two issues this proposal is trying to address: > > 1. Shrink the release cycle. > > 2. Backport things to stable releases. > > We should discuss these separately since together it's hard to discuss. > 1. is less controversial I would think :) > > > > > > > On Tue, Jun 17, 2014 at 1:16 PM, Michael Kjellman < > mkjell...@internalcircle.com> wrote: > > > Totally agree — "Also — i’m aware that any additional branches/releases > > will add additional work for any developer that works on C*. It would be > > great if we could strike a balance that hopefully doesn’t add significant > > additional merging/rebasing/work for the team…” > > > > That being said I don’t think i’m alone by identifying the problem. The > > proposed solution was what we came up with in the hour or so we discussed > > this in person. How else can you shrink the release schedule without > > creating another branch? Also — the idea is to only have this branch > > “active” during the overlap when major release branches need to > stabilize. > > > > > On Jun 17, 2014, at 10:03 AM, Brandon Williams > wrote: > > > > > > If that's what we want, merging is going to be much more painful. > > > Currently we merge: > > > > > > 1.2->2.0->2.1->3.0 > > > > > > If we add an experimental branch for each, we still have to merge the > > > stable branch into experiemental: > > > > > > 1-2->1.2ex, 2.0->2.0ex, 2.1->2.1ex, 3.0->3.0ex > > > > > > And then the experimentals into each other: > > > > > > 1.2ex->2.0ex, 2.0ex->2.1ex, 2.1ex->3.0ex > > > > > > That's quite a lot of merging in the end. > > > > > > > > > On Tue, Jun 17, 2014 at 11:51 AM, Jake Luciani > wrote: > > > > > >> I'm not sure many people have the problem you are describing. This is > > more > > >> of a C* developer issue than a C* user issue. > > >> > > >> > > >> Is the below what you are describing we move to?: > > >> > > >> 1.2 -> 2.0 -> 2.1 -> 3.0 stable > > >> 1.2 <- 2.0 <- 2.1 <- 3.0 experimental > > >> > > >> Specific changes would be backported based on the "less riskyness" of > > the > > >> change which you are assuming will be constant across versions? > > >> > > >> -Jake > > >> > > >> > > >> > > >> > > >> On Tue, Jun 17, 2014 at 12:28 PM, Michael Kjellman < > > >> mkjell...@internalcircle.com> wrote: > > >> > > >>> It's a bit about features - but it's more an attempt to achieve the > > goals > > >>> of what might happen with a 4 week release cycle (but that itself -- > in > > >>> practice didn't prove to be valid/reasonable). > > >>> > > >>> If something like an executor service for performance is changed (for > > >>> example) it is definitely a more risky change than what would > currently > > >> go > > >>> into 1.2 -- but most likely we would want to get patches like that > > into a > > >>> usable build. > > >>> > > >>> So I guess: a) reduce code drift between branches we run in > production > > b) > > >>> get newer "features" into production faster where breaking changes > > aren't > > >>> required for the scope of the patch. > > >>> > > >>> Additionally - it's also a question of what release we use when we > > >>> identify an issue we want to work on internally. If we are on 1.2 > > because > > >>> we can't yet take ALL of 2.0 - do we now need to target our work > > against > > >>> 1.2? I would rather write it against the months worth of changes that > > >> have > > >>> happened since. > > >>> > > >>> Finally, it's an attempt to make the internal forking not as common > as > > it > > >>> might be today. As you said - this is somewhat of a common process. > > >>> > > On Jun 17, 2014, at 8:52 AM, "Jake Luciani" > wrote > > > > Hi Michael, > > > > I didn't get to hear the in person conversation so taking a step > back. > > The proposal seems to be in response to a common problem. i.e. I'm > > on > > >>> C* > > version X and I need feature Y which is only available on version Z. > > Is > > this correct? > > > > The options have been: a) upgrade to version Z or b) fork C* and > > >>> backport. > > Coming my my previous job where I ran a prod C* cluster I felt this > > >> and I > > expect many others do too. We did have to fork and backport patches > > we > > needed and it was hard. > > > > This is specific to features and not bugs, since bugs are fixed in > all > > versions affected. > > > > -Jake > > > > > > > > > > > > > > On Tue, Ju
