On Thursday, 30 May 2013, Chris Graham wrote: > What do we currently do for plugins?
What do we currently do for core? > Is there in difference in the approach taken? No difference. In each case we currently respin failed votes reusing the version number until we get an actual successful vote. > > We call for a vot for vX.Y.Z of <arbitrary plugin> (plugins's [recently at > least] do not appear to go throught he beta/RC phases). That is down to not really having new core plugins recently, and the size of changes being such that the release manager felt there was no need for an alpha/beta Because of the switch from sonatype aether to eclipse aether *and* the exposing of the aether API to plugins, for Maven 3.1.0 jumping straight to 3.1.0 was deemed too risky by the release manager, hence 3.1.0-alpha-1. Personally, given the lack of review the 3.1.0-SNAPSHOTs were getting, this was probably a wise plan... However I think quite a few people have put their eyes on the code by now, so *if* I was the release manager, I'd be tempted to head straight for 3.1.0... Thankfully I am not release manager for this release, so not my problem ;-) (Note: the release manager is just whoever stands up and says "I want to cut a release of XYZ"... Can change with every release, or stay mostly the same. Eg Kristian has been release manager for Surefire by consistently stepping up and cutting releases, but if any other committer wanted to run a release they can step up at any time... It's actually something we encourage newer committers to do (usually starting with smaller plugins though) so that they can get a feel for how our release process works (learn by doing)) > > Can someone please spell out a sequence of events (by time) as to what > happens through the entire process? From prep to vote to ending up in > central. > > Slightly simplified, and there are differences for components vs plugins vs core, but essential principle remains close to this 1. Run `mvn release:prepare release:perform` 2. Send the "[vote]" email 3. Wait 72h (or longer if not enough binding votes and the release manager thinks some more binding votes will turn up) 4. On nexus, promote the staging repo 5. Update JIRA versions 6. Update the component's site (and for plugins the table of plugin versions) 7. Copy the artifacts to dist 8. Wait for "the sync" to central 9. Send "[ann]" email And the same sequnce, but for a failed vote, and it's revoting (we've used > the same version no again, here, have we not?) After step 3, we currently delete the tag, go back to step 1. And release again reusing the same version number from the first time. > > -Chris > > > > On Thu, May 30, 2013 at 6:11 AM, Fred Cooke > <[email protected]<javascript:;>> > wrote: > > > > > > > -1 for actual releases: it would create more mess imo for end users if > > > there's many bizarre jumps in numbering > > > > > > The thing with this argument is that it's very, very weak. If a missed > > version confuses a user, they're basically brain-dead. Assuming your > users > > are brain dead is _always_ dangerous. Assuming the users or a > _development_ > > tool are brain-dead is that in and of itself IMO. > > > > A random example from central that I gave to Robert earlier: > > > > > > > http://search.maven.org/#search|gav|1|g%3A%22antlr%22%20AND%20a%3A%22antlr%22 > > > > I don't know about the rest of you... but I'm not confused by the absence > > of 2.7.3 in any way shape or form. I'm additionally not confused by the > > absence of 2.7.8, 2.7.9, 2.7.10, etc, nor 2.8.* nor 2.9.* It's > meaningless > > to me that they're absent. I use and test a version (usually latest) and > > verify it functions adequately for my needs, then I depend on it (dep or > > plugin equally) and that's it. If I find a flaw, or need to use a new > > feature, then I can go looking for the best version that is compatible > with > > my setup, that contains it (again, likely latest, API change not > > withstanding). > > > > Being worried about developers being confused by a non-sequential set of > > binaries to choose from is bizarre at best. Developers, even the bad > ones, > > are generally a fairly intelligent bunch. > > > > This is not winamp! :-p (nor VLC) > > > > Fred. > > > -- Sent from my phone
