+1 easy to use, very powerful, and produces artifacts consistent with scm and for those who didn't read the doc: prepare [1] and perform [2]
[1] http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html [2] http://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html Le mercredi 26 juin 2013 09:20:40 Olivier Lamy a écrit : > 2013/6/26 sebb <seb...@gmail.com>: > > It would be a lot better to use RC1 RC2 etc initially, and copy the > > successful tag to the GA tag. > > this mean modifying manually the pom to change version (from 1.0-RC1 > to 1.0) before copying teh RC tag, changing the scm information etc... > Rebuild jars ? because if you change the pom it means you change the > sources so need an other build/vote.. > > Frankly currently we have a very simple process which works very fine: > * mvn clean release:prepare release:perform -B (-Dusername= -Dpassword=) > * verifying staging repo > * closing the staging repo > * cd target/checkout && mvn clean site-deploy > * and that's it > > Perso, I don't want we move to something over complicated without any > real added value. > > > 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 > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > --------------------------------------------------------------------- > 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
