Point missed. You said: 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. >
And my point was, it's no change at all, there are already broken "releases" (without the quotes) in an SCM somewhere. So it's no different at all, certainly not radically different. Fred. PS, Stephen, you were lucky! I only got a plate with some cookie crums and an empty glass smelling of lagavulin :-p On Thu, May 30, 2013 at 1:58 PM, Chris Graham <[email protected]> wrote: > No, by their own rules, if the vote passed, then it's 'valid' release. > > That fact that we have more than one release of anything means that we > sometimes get it wrong. > > -Chris > > > On Thu, May 30, 2013 at 8:38 PM, Fred Cooke <[email protected]> wrote: > > > Are you saying that tags for 2.1 and 2.2.0 of Maven itself should be > > deleted because those versions are broken? A tag isn't a guarantee of > > correctness/non-brokenness, it's just a *permanent* record of what a > > particular version contained. The concept of immutability is pretty core > to > > Maven (at least in my mind). When I first witnessed the deletion of tags > > and re-spinning of versions some months ago it was the most disturbing > > thing that's happened to me since I found out that Santa Claus wasn't > real. > > This is (supposed to be) the pinnacle of release engineering, setting an > > example for all to follow, and it's breaking its own rules. I was, quite > > literally, very sad. This seems like an opportunity to fix the situation. > > I'm baffled by some of the things being said, though. > > > > On Thu, May 30, 2013 at 12:26 PM, 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 > > > > > > > > > > > > > > > > > > > > >
