On 30 May 2013 10:30, Chris Graham <[email protected]> wrote: > 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. >
Well to my mind that is also part of the issue.... If we accept that failed tags get deleted, then we should respin reusing the same version number until we have a non-failed tag (irrespective of the reason for the failure) If we don't reuse version numbers, it should be ever, in which case if release:prepare produces a tag that *cannot* complete release:perform (as opposed to just a failure for a single run of release:perform) then we would not delete the tag and run release:prepare for the next version number. In that sense I don't see this as a critical bit... rather I see it as part of what should be covered by the vote. > 2. The copying process to get it in the wild is manual and post vote. > Not quite true, the artifacts are in the wild... just in a staging repository from which they can be deleted. The copy to dist is a legal requirement to ensure the legal protections that the ASF provides remain in force (this is also why the PMC have binding votes, and why the PMC has to concern itself with annoying pesky things like ensuring that the NOTICE.txt has correct content and that files have the correct license headers... I may not, in the past, have fully appreciated the reasons for or the needs for these things... but since becoming a member of the ASF [with the legal responsibilities that come with that] I have gained a different perspective). But there is always concern from people that they will end up with their local repository corrupted as a side-effect of testing. For instance, suppose there is a fix related to how some component works behind a proxy. That may well require you to add the staging repository to your corporate proxy repository (because the machines you want to test from, and perhaps even the scenario you want to test, are required to have a <mirrorOf>*</mirrorOf> in their settings.xml)... in such a case you will end up with the situation that the test machines have downloaded the artifacts into their local repository cache *and* even with the repository source validation that Maven 3.x brings to the table, you will need to manually purge those artifacts from your local repository cache *because* the <mirrorOf>*</mirrorOf> will be forcing the source of those release artifacts to be unchanged. Now one could argue that you shouldn't be adding the staging repo to your proxy in the first place, and instead you should create a special proxy on your repository manager that adds in the staging repo on top of the normal proxy and update the settings.xml to use this new mirrorOf source... but that will force everything to be re-downloaded into the local cache *and* there are test circumstances where one might fear that such a change could affect the validity of your testing. The above, to my mind, is the primary driver for never reusing version numbers... whether it is worthy of the change is for all to decide... My current thinking is though: * if we allow deleting tags because the tag won't complete release:perform, then we should re-use version numbers. * if we don't allow re-using version numbers, then we should not allow deleting tags *just* because the tag won't complete release:perform. And I am considering whether I want to change my 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 > > >
