+1 to change our tags convention if it solves this issue by avoiding to reuse tag names to give a better visibility from where a release was done
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 > > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
