incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Dashorst <>
Subject Re: Ease of release process and exit criteria
Date Fri, 19 Aug 2016 12:49:27 GMT
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

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
- generates messages for vote email, announce email
- pushes release candidate to private staging repository
- generates promote and revert scripts


On Fri, Aug 19, 2016 at 12:18 PM, Mark Struberg
<> 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‘
> 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
> (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:
> hth.
> LieGrue,
> strub
>> Am 19.08.2016 um 11:57 schrieb Bertrand Delacretaz <>:
>> Hi Mark,
>> On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas <> 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
>> 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 ...
>> +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
>> about a repeatable release process? That's a discussion for
>> community.a.o but what's your opinion?
>> -Bertrand
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Become a Wicket expert, learn from the best:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message