One more thing to consider: It's a huge change; as if you do not delete, you now have broken 'releases' in a SCM somwhere, and that is radically different to what is currently there.
I should be able to check anything out now from a tag, build it and have it work. If we allow broken tags, then we could be frustrating a lot of people. It's a huge change of process. And for me, I prefer not to introduce it. We also have maven's concept of immutability, which is a reason NOT to allow the reuse of numbers; however, that does not appear to have been too much of a problem up until now. -Chris On Thu, May 30, 2013 at 7:55 PM, Stephen Connolly < [email protected]> wrote: > 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 > > > > > >
