Yup, or the prepare goal actually has some kind of "auto suggest tagname" option; which involves scanning for existing tags according and proposing a new tag according to the same algorithm.
So when you say you want to release foobar-1.2, it'll actually look for foobar-1.2§1 and auto-suggest foobar-1.2§2 as a tagame (since you already used foobar-1.2§1), since that's the algorithm. and of course, we need a less ridiculous separator :) Kristian 2013/6/28 Robert Scholte <rfscho...@apache.org>: > What we could do is adding some sort of stageTagName to the prepare goal of > maven-release-plugin. > The project will initially be tagged with this value, but the pom.xml still > contains the final tag location. > A new goal could be introduced where you only have to specify the > stagingScmUrl. The plugin can read the final destination from the pom.xml > (or from release.properties if these are still on your system) and do the > copy/move. > > This way we don't have to touch any of the sourcefiles, but we have to > accept that during staging the value of the connection/developerConnection > does not yet match its current scm location. > > Robert > > Op Fri, 28 Jun 2013 18:22:50 +0200 schreef Kristian Rosenvold > <kristian.rosenv...@gmail.com>: > > >> I'll accept any separator as long as we standardize, but I do not >> think mixing internal project process (dealing with tags, votes and >> failed internal release attempts) with the final produced artifact. So >> IMO the project could decide to *stage* and publish foobar-1.0-rc1 >> (which it actually promotes to maven central), >> but might in the release process very well make three private attempts >> before even rc1 is promoted. >> >> That'd make it foobar-1.0-rc§1, foobar-1.0-rc§2 and foobar-1.0-rc§3. >> The tags go in the poms and >> we just keep the final tag as a permanent reference. >> >> I'm also of the understanding that we have no legal obligation to >> match the source to a >> scm revision. But it kinda makes us look slightly more professional >> and I'd quite frankly >> find developing without source control a crazy concept; I'm sure I'd >> be programming php >> at that stage.. >> >> Kristian >> >> 2013/6/28 Mirko Friedenhagen <mfriedenha...@gmail.com>: >>> >>> Kristian, >>> >>> # could lead to a lot of problems when used with dereferencing >>> http-proxies, because it separates the http-url fragment[1]. AFAIK >>> Debian packages use ~ (tilde) as separator for beta packages which has >>> no special semantics AFAIK in URLs. >>> >>> [1] http://en.wikipedia.org/wiki/Fragment_identifier >>> Regards Mirko >>> -- >>> http://illegalstateexception.blogspot.com/ >>> https://github.com/mfriedenhagen/ >>> https://bitbucket.org/mfriedenhagen/ >>> >>> >>> 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 >>>> >>> >>> --------------------------------------------------------------------- >>> 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
