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
