IMO having releases on a 4.0 branch that do not start with 4.0 is very confusing.
By moving to the 4.1 branch we are essentially saying the 4.0.x line is essentially only there for emergency bug fixes. With your logic above, even if the person found a bug on their 4.0.x line they would be able to upgrade to the latest 4.X branch seamlessly. 4.1 should not be incompatible with 4.0 - by the semantic naming Phoenix is currently using (and your example above). I don't really see any reason why we couldn't change it. This is really more of a semantic change, rather than any more actual work. However, by doing this now we set ourselves up for having multiple branches later that could be managed by different RMs if people have issues. If someone else wants to maintain the 4.0 branch, then I think they should be able to. Apache and Phoenix are volunteer efforts, so people can choose to stop working on things when they want or to pick up things that others have left behind. ------------------- Jesse Yates @jesse_yates jyates.github.com On Thu, Aug 21, 2014 at 10:34 AM, James Taylor <[email protected]> wrote: > IMHO, I don't think we have the bandwidth to maintain any more > branches. I'm also not sure this fits the criteria for a lazy > consensus vote. > > The original intent of the 4.0 branch was meant to host all 4.x > releases. In general releases are compatible in the following manner: > - a minor release must be deployed first on the server and then at any > point later on the client. It will require a rolling restart, but no > downtime. > - a patch release may be deployed on the client and server in either > order. If the patch requires the server jar to be deployed (which > would likely be most of the time), it will require a rolling restart > and no downtime will be required. > - a major release may require downtime, as it may require the client > and server side to both be deployed together. > > Given this, the model was that folks would upgrade to the latest > 3.0/4.0 release if they need a particular fix. For example, if someone > is on 4.0.0 and a bug gets fixed down the road in 4.2.5, they should > be able to upgrade as above relatively seamlessly. > > This CDH incompatibility is different. I think we should brainstorm on > that one in a different thread. > > Thanks, > James > > > On Thu, Aug 21, 2014 at 10:08 AM, Andrew Purtell <[email protected]> > wrote: > > Monday 8/25 :-) > > > > > > On Thu, Aug 21, 2014 at 10:07 AM, Andrew Purtell <[email protected]> > > wrote: > > > >> The latest code on branch 4.0 builds as version 4.1.0. > >> > >> I propose the following series of actions: > >> > >> - Create a new branch 4.1 at the revision where the version in the POM > was > >> updated to 4.1.0. > >> > >> - Reset the branch 4.0 head to the version prior, with a force push > >> > >> Let's use lazy consensus ( > >> http://www.apache.org/foundation/voting.html#LazyConsensus) and run > this > >> vote for 72 hours. If nobody objects I will take the above actions > Monday > >> 8/24. > >> > >> -- > >> Best regards, > >> > >> - Andy > >> > >> Problems worthy of attack prove their worth by hitting back. - Piet Hein > >> (via Tom White) > >> > > > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) >
