On Jun 28, 2013, at 7:05, Fred Cooke <fred.co...@gmail.com> 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) 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'. Not so anymore, see http://subversion.apache.org/docs/release-notes/1.8.html Gary 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
