As far as the ASF is concerned, from a legal perspective, the tag is not a release.
The only release is the src.tar.gz in the dist folder or the archives. Tags and binaries are simply a convenience for users. Whether that is something that is important to the Maven community is a different question though. On 30 May 2013 11:26, Chris Graham <chrisgw...@gmail.com> wrote: > 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 < > stephen.alan.conno...@gmail.com> wrote: > > > On 30 May 2013 10:30, Chris Graham <chrisgw...@gmail.com> 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 < > > > stephen.alan.conno...@gmail.com> 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 <fred.co...@gmail.com > > > > <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 > > > > > > > > > >
