Thank you Stephen for taking the time to explain. To me, the key critical bits are:
1. The full normal tag is created, and deleted if failed. If the release process fails (as in release:prepare/release:perform) we often have to delete the tag and manually re-run it anyway. 2. The copying process to get it in the wild is manual and post vote. Given that, I have no problem with respinning a release using the same version, which is, essentially what we have been doing. This is very similar to what I do for the day job. But not the same. In the day job, we through away a release and just create a new one. Why the difference? Simple, the audience for the day job is limited, and the decision to release is driven by the tech lead and immediate. There is no voting process. In this OS world, we are talking about release X.Y.Z (or whatever) and, personally, I remember X.Y.Z. I would quickly get confused if I had to constantly remember that X.Y.Z is now X.Y.(Z+N). Additionally, the vote remains open for a period of time, and I would get lost with the constantly changing numbers. Note, this is not the same as saying anything about skipped public version numbers. For the same reason, I would recommend offering different approaches to core/plugins/whatever: let's not complicate things. So, to that end, -1 (ie respin) for all (non binding) -Chris On Thu, May 30, 2013 at 5:11 PM, Stephen Connolly < [email protected]> wrote: > 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 >
