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

Reply via email to