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 > >
