On Fri, Jun 28, 2013 at 8: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. > > We had that discussion, as already noted here, about three weeks ago, which is why I asked you to drop it, as it had already been well debated.
> 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 do wish you had done what I and others have invited you to do, namely use the release plugin. If you had, you'd have seen that the release plugin uses a svn copy to create the tag. A tag, in this instance is a lebel, or sym link for a revision. In this context, your statement "- a unique SVN coordinate requires the revision and the tree segment selector (e.g. tag)." makes no sense. As, by definition, a SVN revision is unique. That was one of the great advantages of SVN over CVS, atomic commits (ie no partial commits). A tag *IS* a revision and is thus unique. > 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 > >
