Yes, tags are cheap so can be kept until no longer useful. If there are a lot of stale tags it can get difficult to navigate the tags directory, so it makes sense to delete all but the successful tag once the vote has completed. There should be no need to keep failed tags once the vote is complete.
That's what we tend to do on Commons and HttpComponents, except that the tags are immutable. We call them RC1, RC2 etc initially and copy (sometimes rename) to the GA tag on release. On 27 June 2013 01:35, Olivier Lamy <ol...@apache.org> wrote: > Sounds a good idea for me (probably until someone else complain :-) ). > And if that stop discussions and move people to working on code/fixing > issues (i.e something very important for users) that will be great! > > > 2013/6/27 Mirko Friedenhagen <mfriedenha...@gmail.com>: >> Hello there, >> >> when. respinning a release it would of help IMO instead of deleting the tag >> to rename it to e.g. maven-javadoc-plugin-2.9-rc1 using "svn mv". >> >> By means of this you are able to easily diff between e.g. released 2.8 and >> the final 2.9 as well as between 2.9-rc1 and the final 2.9. >> >> Regards Mirko >> -- >> Sent from my mobile >> On Jun 26, 2013 12:14 PM, "sebb" <seb...@gmail.com> wrote: >> >>> On 26 June 2013 10:56, Chris Graham <chrisgw...@gmail.com> wrote: >>> > On Wed, Jun 26, 2013 at 7:06 PM, sebb <seb...@gmail.com> wrote: >>> > >>> >> I meant: if the pom is created with the correct final URLs in the >>> >> first place, it won't have to be changed. >>> >> >>> >> >>> > They are. If you'd used the release plugin, then you would have seen >>> this. >>> > >>> >>> I was responding to this: >>> >>> >>> >>> On 26 June 2013 01:04, Chris Graham <chrisgw...@gmail.com> wrote: >>> > -1 >>> > Except then the poms will point to the wrong place. >>> <<< >>> >>> but maybe I misunderstood. >>> >>> > >>> >> It might need a tweak to the appropriate plugin, but it's not >>> >> impossible to achieve. >>> >> >>> > >>> > You've not clearly stated what it is that you actually intend to achieve. >>> >>> I thought I stated that clearly in my original post at the start of this >>> thread. >>> >>> > >>> >> The same process would work with the system used by Lucene. >>> >> >>> >> No, it wouldn't. From my reading of that email, there appeared to be far >>> > more manual steps involved, and probably a far larger time window >>> involved >>> > as well. But I'd have to grok it a little more to be sure. >>> > >>> > >>> >> >>> >> >>> > On 26 June 2013 06:48, Hervé BOUTEMY <herve.bout...@free.fr> wrote: >>> >> > the jar content isn't updated: so you have jar artifacts inconsistent >>> >> with svn >>> >> > >>> >> > Le mercredi 26 juin 2013 01:08:59 sebb a écrit : >>> >> >> On 26 June 2013 01:04, Chris Graham <chrisgw...@gmail.com> wrote: >>> >> >> > -1 >>> >> >> > Except then the poms will point to the wrong place. >>> >> >> >>> >> >> Depends how the poms are updated. >>> >> >> >>> >> >> > On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory >>> >> > <garydgreg...@gmail.com>wrote: >>> >> >> >> On Tue, Jun 25, 2013 at 7: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. >>> >> >> >> >>> >> >> >> +1 ! :) >>> >> >> >> >>> >> >> >> Gary >>> >> >> >> >>> >> >> >> > 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 >>> >> >> >> >>> >> >> >> -- >>> >> >> >> 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 >>> >>> > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > --------------------------------------------------------------------- > 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
