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) 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 > >> >> *not* to the version. > >> >> - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as > >> >> maven-foo-2.16 using the SCM directly. > >> >> - The version stays enduser friendly and the tag in the pom points to > >> the > >> >> sources correctly. > >> >> - Diffing between different RCs and the final versions is easy. > >> >> - No one has to fiddle with invalid workspaces/clones. > >> >> - For the release manager it is just one additional SCM call. > >> >> > >> >> Regards Mirko > >> >> -- > >> >> Sent from my mobile > >> >> On Jun 27, 2013 4:42 PM, "sebb" <seb...@gmail.com> wrote: > >> >> > >> >>> On 27 June 2013 15:05, Ralph Goers <rgo...@apache.org> wrote: > >> >>>> I do not believe that can be done with the release plugins as the > pom > >> >>> has to specify the same version as the tag. If you then rename the > >> tag you > >> >>> would have to modify the poms in the tag, which makes the release > >> invalid. > >> >>>> > >> >>>> Have you ever used the release plugin? If not, I would suggest you > >> try > >> >>> it and offer up patches to change it instead of carrying on this > >> discussion > >> >>> as it is unlikely maven is going to stop using the release plugin. > >> >>> > >> >>> This is straying further off the original topic. > >> >>> > >> >>> Whether people use the release plugin or some other method is not > >> >>> really relevant to the release vote itself. > >> >>> > >> >>> All the process that leads up to the vote is merely a means to > trying > >> >>> to ensure that the release candidate as as good as possible. > >> >>> > >> >>> What matters is the vote - the public declaration that the RC has > been > >> >>> reviewed and approved. > >> >>> Only a PMC-approved vote can get the legal protection of the ASF. > >> >>> > >> >>> The vote needs to be performed on input that can be readily checked > by > >> >>> any reviewer. > >> >>> The vote has to be seen to be open and complete. > >> >>> The SVN (or GIT) coordinate is an essential part of the input, as it > >> >>> is the only practical way to check provenance of the files in the > >> >>> archives. > >> >>> > >> >>> Given that part of the Maven philisophy is to ensure that all plugin > >> >>> versions must be specified to ensure repeatable builds, I'm a bit > >> >>> surprised how much resistance there is to providing the specific > >> >>> source which was used as input to the build process. > >> >>> > >> >>> The only change that this requires to be made to the process is to > add > >> >>> the revision number and tag name [1] to the release vote e-mail. > >> >>> Is that really too much to ask? > >> >>> > >> >>> [1] A revision on its one is insufficient as the ASF uses a shared > SVN > >> >>> repo; the location within the tree is needed to be able to select > the > >> >>> revelant portion of the tree. The tag name is one such way to > provide > >> >>> the information. > >> >>> > >> >>>> Ralph > >> >>>> > >> >>>> On Jun 25, 2013, at 4:14 PM, sebb <seb...@gmail.com> wrote: > >> >>>> > >> >>>>> It would be a lot better to use RC1 RC2 etc initially, and copy > the > >> >>>>> successful tag to the GA tag. > >> >>>>> > >> >>>>> On 25 June 2013 19:38, Ralph Goers <ralph.go...@dslextreme.com> > >> wrote: > >> >>>>>> Yeah - I agree with this. I rename them to rc1, rc2, etc after a > >> >>> failed release vote instead of deleting them. > >> >>>>>> > >> >>>>>> > >> >>>>>> On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: > >> >>>>>> > >> >>>>>>> On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers < > >> >>> ralph.go...@dslextreme.com>wrote: > >> >>>>>>> > >> >>>>>>>> Again I have to disagree. The release manager will send an > email > >> >>> closing > >> >>>>>>>> the prior release. At this point all the prior release > artifacts > >> >>> are junk > >> >>>>>>>> even if they still exist. At some point the release manager > will > >> >>> delete > >> >>>>>>>> the tag and rerun the release > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> That's a no-no IMO. Tags that have been voted on should never be > >> >>> deleted. > >> >>>>>>> > >> >>>>>>> Gary > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>>> At this point the tag is still junk to everyone else because > they > >> >>> have no > >> >>>>>>>> idea what the RM is doing - so they shouldn't be making > >> assumptions > >> >>> about > >> >>>>>>>> non-released tags. Once he sends the email though the tag > will be > >> >>> valid. > >> >>>>>>>> Sure having the revision number helps but unless the RM > completely > >> >>> screws > >> >>>>>>>> up the tag should be sufficient. > >> >>>>>>>> > >> >>>>>>>> Ralph > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote: > >> >>>>>>>> > >> >>>>>>>>> Not really, no. The developer may have re-spun it again and be > >> >>> about to > >> >>>>>>>>> email again. You have no idea what you're looking at unless > you > >> >>> know the > >> >>>>>>>>> revision. SVN will die off within a decade and this discussion > >> will > >> >>>>>>>> become > >> >>>>>>>>> critical. Better to figure out how to support proper > techniques > >> now, > >> >>>>>>>> rather > >> >>>>>>>>> than wait until forced to. > >> >>>>>>>>> > >> >>>>>>>>> On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers < > >> >>> ralph.go...@dslextreme.com > >> >>>>>>>>> wrote: > >> >>>>>>>>> > >> >>>>>>>>>> I disagree that the revision is required. I know that the > RM is > >> >>> going > >> >>>>>>>> to > >> >>>>>>>>>> recreate the tag with each release candidate. Therefore, so > >> long > >> >>> as I > >> >>>>>>>>>> refetch that tag for every release vote I can be confident > that > >> I > >> >>> am > >> >>>>>>>>>> reviewing the release contents. > >> >>>>>>>>>> > >> >>>>>>>>>> Ralph > >> >>>>>>>>>> > >> >>>>>>>>>> On Jun 25, 2013, at 9:52 AM, sebb wrote: > >> >>>>>>>>>> > >> >>>>>>>>>>> The mission of the ASF is to release software as source, > and to > >> >>> ensure > >> >>>>>>>>>>> that the released source is available under the Apache > Licence. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Before a release can be approved it must be voted on by the > >> PMC. > >> >>>>>>>>>>> The review process needs to establish that the proposed > source > >> >>> release > >> >>>>>>>>>>> meets those aims. > >> >>>>>>>>>>> > >> >>>>>>>>>>> It's all but impossible for reviewers to examine every > single > >> >>> file in > >> >>>>>>>>>>> a source archive to determine if it meets the criteria. > >> >>>>>>>>>>> And it's not unknown for spurious files to creep into a > release > >> >>>>>>>>>>> (perhaps from a stale workspace - are releases always built > >> from a > >> >>>>>>>>>>> fresh checkout of the tag?) > >> >>>>>>>>>>> > >> >>>>>>>>>>> However, PMCs are also required to check what is added to > the > >> SCM > >> >>>>>>>>>>> (SVN/Git) to make sure it meets the required license > criteria. > >> >>>>>>>>>>> This is done on an ongoing basis as part of reviewing > check-ins > >> >>> and > >> >>>>>>>>>>> accepting new contributions. > >> >>>>>>>>>>> So provided that all the files in the source release are > also > >> >>> present > >> >>>>>>>>>>> in SCM, the PMC can be reasonably sure that the source > release > >> >>> meets > >> >>>>>>>>>>> the ASF criteria. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Without having the SCM as a database of validated files, > there > >> >>> are far > >> >>>>>>>>>>> too many files in the average source archive to check > >> >>> individually. > >> >>>>>>>>>>> And how would one check their provenance? The obvious way > is to > >> >>>>>>>>>>> compare them with the entries in SCM. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Therefore, I contend that a release vote does not make sense > >> >>> without > >> >>>>>>>>>>> the SCM tag. > >> >>>>>>>>>>> In the case of SVN, since tags are not immutable, the vote > >> e-mail > >> >>> also > >> >>>>>>>>>>> needs the revision. > >> >>>>>>>>>>> > >> >>>>>>>>>>> Whether every reviewer actually checks the source archive > >> against > >> >>> SCM > >> >>>>>>>>>>> is another matter. > >> >>>>>>>>>>> But if the required SCM information is not present, it > would be > >> >>>>>>>>>>> difficult to argue that the RM had provided sufficient > >> >>> information for > >> >>>>>>>>>>> a valid review to take place. > >> >>>>>>>>>>> > >> >>>>>>>>>>> > >> >>> > --------------------------------------------------------------------- > >> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >>>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>> > --------------------------------------------------------------------- > >> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> --------------------------------------------------------------------- > >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> -- > >> >>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > >> >>>>>>> Java Persistence with Hibernate, Second Edition< > >> >>> http://www.manning.com/bauer3/> > >> >>>>>>> JUnit in Action, Second Edition < > http://www.manning.com/tahchiev/> > >> >>>>>>> Spring Batch in Action <http://www.manning.com/templier/> > >> >>>>>>> Blog: http://garygregory.wordpress.com > >> >>>>>>> Home: http://garygregory.com/ > >> >>>>>>> Tweet! http://twitter.com/GaryGregory > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> --------------------------------------------------------------------- > >> >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >> >>>>> > >> >>>>> > --------------------------------------------------------------------- > >> >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >> >>>>> > >> >>>> > >> >>>> > --------------------------------------------------------------------- > >> >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >>>> For additional commands, e-mail: dev-h...@maven.apache.org > >> >>>> > >> >>> > >> >>> > --------------------------------------------------------------------- > >> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >>> For additional commands, e-mail: dev-h...@maven.apache.org > >> >>> > >> >>> > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> > > > > > > -- > > ----- > > Arnaud Héritier > > http://aheritier.net > > Mail/GTalk: aheritier AT gmail DOT com > > Twitter/Skype : aheritier > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
