On Feb 13, 2014, at 10:03 AM, Stephen Connolly <[email protected]> wrote:
> 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 > I plan on continuing some refactoring in the core. I also think with some of the added extension points, and a few more that all the features we want in 4.0 can be a clean superset on 3.x. This was part of the thinking in how 3.x was designed. All the new POM format work can be done with what's currently there, almost everything I can think of can be done. Mixins would be nicer with a small change in the model builder but a form can be done with what's there now. > 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 > I don't think we need to EOL it, nor should we. I think most users are on 3.x now but just barely the majority. As I said above I don't think there are any features we want in 4.0 that can be done with extensions to the core. The frequency of releases will happen when more people work on the core. I don't think there is any magic that is going to make releases come out faster. > -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 >> >> >> >> >> >> >> >> >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- We know what we are, but know not what we may be. -- Shakespeare
