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
