On Thu, Jun 27, 2013 at 4:39 PM, Jason van Zyl <ja...@tesla.io> wrote: > Agreed. > > Our tooling and policy is embodied in the release plugin. I am personally > fine with any policy changes that are required, but would argue anything we > have is grandfathered in because we've been doing it so long. If changes are > required, my requirement is that I do nothing more than I currently do which > is to use the release plugin. I agree with Ralph that your avenue of change > is by altering the release plugin because this discussion isn't going to > result in anything unless it results in changes to the release plugin.
+1 http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi > > On Jun 27, 2013, at 10:05 AM, 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. >> >> 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 >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > Simplex sigillum veri. (Simplicity is the seal of truth.) > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
