On 18 February 2014 23:58, Jason van Zyl <ja...@takari.io> wrote: > > On Feb 18, 2014, at 3:20 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > Well for one that is not how RM works or has worked here. > > > > Really? When I have planned to release core it takes some effort that > requires more effort than the normal components. So if it's not clear from > trying to curate the issues for the next release and working on the core > with the intent to release 3.2.2 when those issues are complete. > > > It's not a hat you keep. It is a hat you put on when you send the mail > > saying "I am intending to cut a release in the next _ days" > > > > All implied, nothing stated and I have always done a series of core > releases because otherwise the overhead is generally pretty high. For a > plugin maybe you can just do a couple days work and do a release but this > is not how it works for the core. > > > If somebody objects then you take that on board as you see fit. Any > > committer can step up and say they intend to cut a release of our > > components. There is no persistent or sticky RM role. > > > > You assume that the core RM is not sticky, I assume it is. If there is a > huge gap sure, and like I said if after this 6 month gap you want to ask > the group to have a new RM then you can. Otherwise I viewed it as implied > with the work done of late that I am the RM for the next core release. So > I'll state it explicitly that I plan to release 3.2.2. > > > I am happy with you cutting releases of core... in fact I am happy with > > anyone who isn't me cutting releases of core or any plugin... largely > > because it means less work for me... > > > > There is, however, a problem if we don't get more people acting as RM for > > any releasable from our project... > > > > If you haven't cut a release, you fear the unknown involved in cutting a > > release. > > > > My aim is to make releasing Maven core a non-event and trivially easy to > > do. That has many benefits, not least making our work easier and getting > > fixes into users sooner. > > > > Yes we could start with a less ambitious time frame, but my experience is > > that it is easier to start with the small release deltas that come from > > short time between releases and slow down if necessary. > > > > If you start with a process that is too fast, you are starting with a > > process that is broken and slowing down until it is working. > > > > If you start with a process that is too slow, you are speeding up until > it > > breaks > > > > I do have to wonder what you are afraid of? > > > > You tend to work in branches and merge features when ready, so if you are > > the only one making changes the build will have nothing to suggest until > > you merge your branch to master. > > > > If other people have fixes for specific issues, what is wrong with > letting > > users get those fixes if they want. > > > > Any one can fix anything they like. Michael and Robert added some fixes > and improvements and they have gone in, and they were basically released a > week or two after the fixes went in, but if they waited for a few more > weeks I don't really see it as an issue. I have the opposite experience as > you and organization's infrastructure does not change weekly, monthly or > even quarterly. So taking more time and collecting changes is not a bad > thing. I see little to no value for the majority of users and if we want > people to try things we should make the nightlies very easy to consume. > This does not require official releases. Anyone can get fixes whenever they > want if we make it easy. This should just happen automatically and I think > is a good thing. Official releases require a support commitment which I > consider important and more of them is harder. > > > I'll make a deal with you, lets see how you feel after 1 month. I suspect > > we will maybe have 1 release during the first month anyway... and may > well > > have none... but if we don't try we will never know. > > > > I assumed I am the RM for 3.2.2 and I plan to release it when that list is > done. I am vehemently against official weekly releases and this will > require a discussion if this is to change. If you want to call them alphas > or nightly and we make those easily available I have nothing against that > and serves the small segment of the population that will try new things > aggressively. If that falls into a pattern of availability for a 6 week > release schedule that would be great. Ultimately anything built at any time > should be a candidate for a release and those should be available for > people to try but I don't think they should be official releases that we > officially support. > > So maybe these are not nightlies but promoted nightlies that have fixes > for those who really require them. >
If they are releases that we intend users picking up, then there needs to be a vote. I don't mind if we call these 3.2.2-alpha-x releases or some other version. The simple fact is that -SNAPSHOTs do not get tested. Things called alpha or beta don't get tested, and if we want to stick to semver type version numbers then 3.2.x is really just bug fixes and anything else is 3.3.x. I am not suggesting weekly releases for 3.3.x only for 3.2.x So for example MNG-5577, from what I understand, is an API change... a backwards compatible one true... but still not a bug fix... so perhaps significant enough that it should be 3.3.x... (and remember this experiment only targets 3.2.x) Precisely because we have held back releases we end up in this state where we are afraid to bump minor or major versions because we do not have enough changes in them... and then we try to cram more changes into what should be patch releases. A patch release is to fix a bug... if it is an improvement then IMHO it should be in the next minor version... if it is a breaking change then the next major... If you see a different scope of what should be in for 3.2.2 (or 3.2.3 if the vote for 3.2.1 fails) then there is a different disconnect there. If we want to show that Maven is listening to users, sticking to patch releases fix bugs, minor releases add features, major releases may break things is what users want... and if we are only fixing bugs in 3.2.x then what is the issue? The bug is fixed, let's get that fix in the hands of our users. > But if anyone else thinks weekly releases are good speak up. I don't think > we can really support them properly. I think 6 week releases would be > fantastic and should be the first goal we strive for. Weekly releases to me > are not valuable to most, generally not going to be consumed and not a > great in practice. Continuous delivery with a stream of viable builds taken > from the normal build stream would be great. Let people take those as fast > as they can. But releases we should try to have better release notes > (historically ours have been pretty terrible, myself particularly, > admittedly) and generally a useful collection of fixes and hopefully > features. I really doubt anyone would care about weekly Maven releases, > it's just too much to absorb. > > > -Stephen > > > > > >>> If you want to cut the releases, super. But I recognise that cutting > >>> releases is work and switching to (max) one per week may be too much of > >> an > >>> ask for you. > >>> > >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > A party which is not afraid of letting culture, > business, and welfare go to ruin completely can > be omnipotent for a while. > > -- Jakob Burckhardt > > > > > > > > > >
