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
