On 13 February 2014 14:51, Jason van Zyl <[email protected]> wrote: > I've proposed the shorter vote period and criteria for releasing. I think > if the ITs pass and it is for fixes to regressions, changes that we are > marking as provisional, or functionality that have no API implications > (like improvements to the CLI) I think those point releases can go out as > soon as possible. For new features or APIs we will have to support > indefinitely, no. >
That is why I am suggesting the 3.2.x branch only Once we get the first 3.2.x release out I envision we will start on 4.0.x So 3.2.x will really be maintenance mode ;-) We should probably declare all of 2.x end of life... I'd be happy to say 3.0.x is end of life too if others agree... but those are for other votes -Stephen > > This is also all predicated on there being things to release and work > being done in the core. It would also help to have the release be fully > automated as right now if someone who hadn't done a core release casually > tried to do a release I don't think they would have much fun. It's quite > tedious. It should be push button. > > On Feb 13, 2014, at 8:39 AM, Stephen Connolly < > [email protected]> wrote: > > > So I am thinking that we have gotten into this habit of holding onto > > changes in core far far too long. > > > > I think it might *help* the community if we tried to move releases out > > faster. > > > > The idea would be that we set up a set of conditions for a release, e.g. > > > > * If there are no changes to the 3.2.x branch since the last release > > (and at least _X_h since the notification landed on the commits list - > see > > voting below for the _X_ value) then there will be no release, otherwise > > those changes are the scope of the potential candidate. > > > > * If the potential candidate passes all integration tests, then the > release > > manager will cut the release candidate based on the potential candidate. > We > > would cut releases on a defined day in the week. The version number will > > not be reused. > > > > * There would be a vote to release the release candidate. For now we will > > say that the standard 72h voting rules will apply, but we may put a > > proposal before the board to define a set of conditions whereby the > voting > > period can be shorter, i.e. (72-_X_)h unless there is an absence of > > consensus. > > > > * If there are any issues with the release candidate, we drop it on the > > floor and forget about it, no respinning. > > > > Repeat the above every week. > > > > I would propose an 3 month experiment with the above process (starting > once > > we get the first 3.2.x release out) > > > > There are some open issues I can think of: > > > > 1. How do we pick the release manager > > 2. Will there be PMC fatigue in voting on releases > > > > Thoughts anyone? > > > > -Stephen > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > The modern conservative is engaged in one of man's oldest exercises in > moral philosophy; that is, > the search for a superior moral justification for selfishness. > > -- John Kenneth Galbraith > > > > > > > > > >
