I would personally love it if we came up with some best practices for new projects as they're coming in. There's been a few very questionable ones done in the past, not that they're bad or incorrect, but do become burdensome. However, I've seen projects create amazing releases in short periods of time. So then why don't those projects graduate already?
John On Fri, Aug 19, 2016 at 6:18 AM 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 > >
