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
