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
