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
