I don't see a point to have branch-2 from branch-1. For customer/users, we always can have a 1.x release to give them all the features they want from branch-1.
My understand is that one of the difference of major release and minor release is that major release could break some backward compatibility. If any features that in master, but not in branch-1, as long as not breaking backward compatible, the owner of the feature always can back-port to branch-1 if they desire. Today we don't have voting process to block that. For 2.0 release or future major release, what we need is planning - THEME (what is the biggest excitement for the release) and MUST-HAVE FEATURES. All must-have features should have an owner and some estimate of completing time. Once the consensus is reached, then next step is execution - the release time would be based on progress of these must-have features. Thanks Stephen On Thu, Mar 9, 2017 at 11:53 AM, Ashu Pachauri <ashu210...@gmail.com> wrote: > In my opinion, a major release is based on two simultaneous decisions: > > 1. Is it time; may be a year is a good time frame? (It's useless > accumulating too much code that is not battle tested and then expect people > to deploy it to production without experiencing a plethora of issues.) > > 2. Is there at least one "major feature" that is complete ? > > I think if we can answer yes to both these questions at any point in time, > it's a good idea to cut the RC and ask people to start testing it. > > the only way forward for saving 2.0 at this point is to *make the branch > and > > spin the RC > > +1 > > > On Thu, Mar 9, 2017 at 11:25 AM, Andrew Purtell <apurt...@apache.org> > wrote: > > > The only way forward for saving 2.0 at this point is to *make the branch > > and spin the RC. *Just do it. Kick out by revert what obviously isn't > > ready. Solicit help in getting partially finished things into working > > state. Kick them out too if the help does not arrive. > > > > Maybe too much is in a half done state and the scale of effort for those > > reverts is too high. Fine. Renumber master as 3.0, and make a branch-2 > from > > branch-1 and backport a select number of things from master into the new > > branch-2. Then release. I do a variation of this for the $dayjob so would > > be your man to turn to for driving this if that's the way forward. > > > > I know it's easy to recommend the labor of others. Depending on what we > are > > going to do I can talk to work about freeing up time to help. > > > > > > On Thu, Mar 9, 2017 at 11:18 AM, Stack <st...@duboce.net> wrote: > > > > > On Thu, Mar 9, 2017 at 12:34 AM, Phil Yang <yangzhe1...@apache.org> > > wrote: > > > > > > > > > > > > So my suggestion is cutting branch-x faster and have some fixed > period, > > > for > > > > example, six month or one year? > > > > > > > > > > > > > You are right Phil. > > > > > > The Release Managers for the minor releases have been doing a good job > > > keeping up a decent release cadence but we have an abysmal track record > > > when it comes to pushing out majors. First we were afraid to commit -- > > > witness how long it took us to get to a 1.0 -- and then pushing out the > > 1.0 > > > took a monster effort. 2.0 looks to be a repeat of the errors of 1.0. > My > > > sense is that 2.0 is beyond saving at this stage. > > > > > > Can we do 3.0 different? As per your suggestion? > > > > > > St.Ack > > > > > > > > > > > -- > > Best regards, > > > > - Andy > > > > If you are given a choice, you believe you have acted freely. - Raymond > > Teller (via Peter Watts) > > > > > > -- > Thanks and Regards, > Ashu Pachauri >
