Looking for common ground here, how about we start by documenting the core release procedure so that someone else could plausibly take a turn? Without knowing the details of the release process, I don't see how I could disagree with JvZ.
It mostly seems to me that Stephen's desired schedule could best arrive organically; it we make fixes in the core that people care about, and if we make the procedure easy, we can make more releases. If that verges on every N weeks, OK, we make a schedule. On February 18, 2014 7:23:19 PM EST, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: >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 >> >> >> >> >> >> >> >> >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
