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
