Someone else already covered that. The tag can live forever as it always was in the POM. In the SVN version you can either lie before or after, in the Git version you can use final or RC and they'll end up pointing at the same commit. Having said that, I never understood why that was done anyway. My poms don't even have the tag XML tag in them and the release plugin rudely inserts it and then removes it again (and butchers the formatting in the process...). It'd be nice to turn that off, though that's another discussion for another day.
This "SCM is convenience" comment keeps popping up. I strongly disagree. You have two requirements: 1) Keep ASF legal people happy 2) Produce quality software artifacts SCM is absolutely essential for the second goal. Are you saying that Uwe and the Lucene project are violating ASF protocol by voting on the SCM revision and only then building/tagging/etc? SCM (even SVN) gives you a fundamentally solid and reliable way to KNOW what's there. Voting on a hash or rev number and then building from it afterward seems like a good move and would save a lot of drama. In terms of providing temporary artifacts to judge that SCM hash/rev by, that's what SNAPSHOT builds are for... Fred. On Fri, Jun 28, 2013 at 2:21 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Friday, 28 June 2013, Fred Cooke wrote: > > > For git the unique hash is sufficient, you don't really need the tag at > > all, they simply point to the unique hash (or another tag, in a chain). > If > > Git was the SCM of choice, I'd use RCX tags, and then not retag for > final, > > but rather point the final tag AT the last, accepted RC tag. > > > > For example > > > > artifact-RC1 >> 1234567890ABCDE > > artifact-RC2 >> ABCDE1234567890 > > artifact-RC3 >> 12345ABCDE67890 > > artifact >> artifact-RC3 (yes this is possible! and is correctly resolved > > to the hash pointed to by the final chain-link) > > > And how exactly do we bake the hash into the Pom? > > We need to know what we are baking into the Pom *before* we can commit the > Pom > > So in the GIT world, we need to bake a tag into the Pom as we cannot > predict the hash. > > In the Subversion world, we need to bake a tag without revision into the > Pom as we cannot predict the revision we will get when we do commit. > > I am fine with saying for GIT *votes* the hash of the tag should be > included in the vote email, but pushing the tag at the time of the vote I > see as a bad plan (unless we decide to change the tag naming convention) > > Subversion does not let us avoid committing the tag, so in that case I am > fine with saying in the vote email tag@1234342 > > But I don't see (given the way the version numbering vote went) why we need > to do anything other than the above 1 small change to the vote emails.... > And keep in mind that given that SCM is just a convenience, even that is > not strictly necessary... It is the -src.tar.gz that we are voting on... > Everything else is just a convenience > > > > > > If I were forced (at gun point) to use SVN again, I'd not create real > > SVN-tags, I'd modify my tooling to either add SVN meta data linking name > > and revision number and path or do the same in a plain text file(s) > > somewhere in the repo. The entire SVN cp thing leaves me feeling ill. SVN > > mv makes me want to cry like a girl. From the help info: > > > > Note: this subcommand is equivalent to a 'copy' and 'delete'. > > > > > > > If only file systems were this good! :-p > > > > In terms of current SVN usage, the "SVN mv" command is probably a good > > choice, as already discussed. You could argue that a "cp" would be > better, > > but this creates wholesale duplication, which is never good. > > > > Fred. > > > > On Fri, Jun 28, 2013 at 12:35 PM, sebb <seb...@gmail.com> wrote: > > > > > The re-use of tags is a side-issue to this thread, though I'm glad to > > > see some support for using immutable tags, whatever route is chosen > > > Please start a new thread to continue that discussion. > > > > > > The vote e-mail must have the revision and tag name/trunk URL in it > > > else it is not complete. > > > > > > Just as Maven insists on GAV - where V=version - a unique SVN > > > coordinate requires the revision and the tree segment selector (e.g. > > > tag). > > > I don't know what Git needs - I suppose it may depend on whether > > > multiple components are part of the same Git instance. > > > > > > But whatever - as it stands, the current vote e-mail is > > > **incomplete**; it does not provide sufficient information for the > > > candidate to be properly evaluated. > > > The information needs to be present both for current and historical > use. > > > > > > On 28 June 2013 10:09, Arnaud Héritier <aherit...@gmail.com> wrote: > > > > +1 to change our tags convention if it solves this issue by avoiding > to > > > > reuse tag names to give a better visibility from where a release was > > done > > > > > > > > > > > > On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold < > > > > kristian.rosenv...@gmail.com> wrote: > > > > > > > >> This suggestion is much like what we came up with the last time > > > >> we discussed this - about 3 weeks ago. > > > >> > > > >> This behaviour is simple to achieve without a single line > > > >> of change; the release plugin already asks for a SCM tag name > > > >> distinct from the version number. (we *could* add some kind > > > >> of support for an explicit convention, we could even add a > scm-lookup > > > >> to auto-roll forward on subsequent takes). > > > >> > > > >> Now I've been trying to think if there's a sensible convention > > > >> that could be established that would allow us to > > > >> simply *keep* the tag name of the accepted version > > > >> without re-pushing another tag after release (and, since the tag > > > >> name can be etched into the pom of the released artifact, there > > > >> should be no real reason for confusion). > > > >> > > > >> I've been thinking about a *tagging* convention along the lines > > > >> of "maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2, > > > >> maven-xx-plugin-2.3.2#3..." > > > >> > > > >> Effectively we would delete #1 and #2 and keep the #3 tag, since > this > > > >> vote passed on take 3. > > > >> > > > >> maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the > > > >> released 2.3.2 version. > > > >> > > > >> This is mostly a policy change on tag naming, we could implement > this > > > >> without a line > > > >> of code change. Since both svn and git essentially have flawed tag > > > >> handling it makes sense to do a change like this. > > > >> > > > >> Kristian > > > >> > > > >> 2013/6/28 Ralph Goers <ralph.go...@dslextreme.com>: > > > >> > Can you provide the steps required to get the release plugin to > work > > > >> this way? > > > >> > > > > >> > Ralph > > > >> > > > > >> > On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote: > > > >> > > > > >> >> Hello, > > > >> >> > > > >> >> this seems to be the most popular discussion, so another 2 cents: > > > >> >> - Today I read the man page of git-tag again. > > > >> >> - It states very clearly you should never reuse tags, because > > unlike > > > is > > > >> the > > > >> >> case with subversion, once a git tag is out in the wild (and > > pushing > > > to > > > >> >> git-wip is the jungle here), everyone who has fetched the tag > would > > > >> have to > > > >> >> delete it *manually* from her copy, otherwise it will point to > the > > > wrong > > > >> >> hash eternally. > > > >> >> > > > >> >> Another approach: > > > >> >> - Always attach the rc-number to the tagname, e.g. > > maven-foo-2.16rc1, > > > >> but > > > > > -- > Sent from my phone >
