Nicely pointed out. If a release is strictly speaking, the source bundle, then I have even less of an objection to respinning a release.
-Chris On Thu, May 30, 2013 at 8:39 PM, Stephen Connolly < [email protected]> wrote: > 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 <[email protected]> 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 < > > [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 > > > > > > > > > > > > > > >
