For Wicket I've crafted a release script that not only creates the artifacts to vote on, but also generates the messages needed for voting and announcing, and scripts to either promote or rollback a release.
https://github.com/apache/wicket/blob/master/release.sh It uses the aforementioned settings for the release plugin, and more. Features: - checks if the release is mentioned in the changelog - checks if there's a remote staging git repository - asks for the new version number - opens/closes/promotes releases in repository.apache.org - generates messages for vote email, announce email - pushes release candidate to private staging repository - generates promote and revert scripts Martijn On Fri, Aug 19, 2016 at 12:18 PM, Mark Struberg <strub...@yahoo.de.invalid> wrote: > Good links. > > I’d like to add some information for projects who use GIT with maven: > > First and important: configure the maven-release-plugin to operate ‚locally‘ > https://github.com/apache/deltaspike/blob/master/pom.xml#L123 > > The important parts are > <pushChanges>false</pushChanges> > <localCheckout>true</localCheckout> > > This will configure maven to NOT push you changes upstream to the repo > mentioned in the SCM section, but only keep it local. > And during the release:perform this will also pick up the tag from local. > That means you need to push it to e.g. github yourself. > > Note that in most projects we do _not_ push the release candidate directly to > the ASF repo but e.g. to the release managers private github account. > Reason is that we cannot easily get rid of it from the cannonical ASF repo if > the VOTE fails. > (ASF repos get mirrored downstream in seconds, and while we could technically > remove it from our own repo we have no control over all the clones). > > This is kind of symetrical to the maven repo staging aproach. > And the sha1 is the same anyway if we merge the buid-branch to master and > push it to the ASF repo later (when the VOTE did pass). > > Something very old I wrote up for DeltaSpike a few years ago where I > described the steps: > http://mail-archives.apache.org/mod_mbox/deltaspike-dev/201309.mbox/%3c1378906506.82251.yahoomail...@web28902.mail.ir2.yahoo.com%3E > > hth. > > LieGrue, > strub > > >> Am 19.08.2016 um 11:57 schrieb Bertrand Delacretaz <bdelacre...@apache.org>: >> >> Hi Mark, >> >> On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas <ma...@apache.org> wrote: >>> ...I'm thinking of a graduation criteria long the lines of: >>> "Is the release process clearly documented to the point that someone new >>> to the project could produce a release build?"... >> >> I like this - as another example we have >> http://sling.apache.org/documentation/development/release-management.html >> in Sling, and as someone who does releases in bursts that's very >> useful. >> >>> ...If there is general consensus on this, I'm happy to draft something to >>> add to http://incubator.apache.org/guides/graduation.html#releases ... >> >> +1 and it's good to add links such as the ones you mentioned and the >> above if you think they are good examples. >> >> How about also adding an RE50 item to >> https://community.apache.org/apache-way/apache-project-maturity-model.html >> about a repeatable release process? That's a discussion for >> community.a.o but what's your opinion? >> >> -Bertrand >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Become a Wicket expert, learn from the best: http://wicketinaction.com --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
