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.
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
