You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Leo Simons <ma...@leosimons.com> on 2006/01/16 20:53:58 UTC
Release Management
Release and build processes
Hi gang,
since I missed a lot of the initial talks, I'm writing this seperately. There
are a lot of "gotchas" related to release management. The ASF has historically
been real good at it and really lousy at creating a documented policy. Stuff
like
* There should be a documented and straightforward and automated way to
re-generate any release or relase snapshot "n" years from now. All the
artifacts for doing that should live in SVN. Eg we want to be able to do
$ svn co http://.../tags/....
$ cd ....
$ sh release.sh
$ wget http://www.apache.org/dist/harmony/..../.....tgz.sha1
$ openssl dgst -sha1 -verify .....tgz.sha1 .....
Verification OK
$
or get as close to something like that as possible.
* Releases should be properly GPG-signed, with SHA1 digest provided as well,
etc etc.
There is documentation on release management somewhere on
http://www.apache.org/dev/
(sorry, no network as I type). There are incubation rules pertaining to
publishing releases and/or snapshots somewhere on
http://incubator.apache.org/
I know I've previously written about this stuff to several mailing lists and
several wiki pages, IIRC by head something like
http://wiki.apache.org/excalibur/ReleaseManagement
should still exist. (I think at some point about 20% of the files on
www.apache.org/dist/ where owned by me and I was the biggest policy-breaker
in terms of bad symlinks, messed up file permissions, missing GPG signatures
so I *had* to figure out some "right way" to do stuff...I still haven't fixed
all my problems there I believe...)
The thing I just want to stress right now...
**Do not take this stuff lightly.** Apache is one of the most trusted names in
the world when it comes to distributing large amounts of quality software and we
have a responsibility to keep up the standard. All contributors and committers
should take some time to review these links and all the technical details
related to building and publishing releases. It might also be a good idea to
read eg dev@httpd.apache.org and look at their commit logs and the like to get
a feeling for what a "mature" release management process looks like here at the
ASF. It pays off bigtime to get a sound and solid release process in place
ASAP. Eg the distro script for JCHEVM in etc/ is a good start.
Its a good idea to tackle doing a release process incrementally, so by all means
"just get started" and publish some of those snapshots. Just make sure we're
complying with all the relevant policies (URLs above). I wish I had
some time to commit to help out writing down some tips 'n tricks or better yet
writing some scripts to help with this and getting a gump run going, but I don't
think I have that time at the moment :-/.
Just some random rants, I'm sorry about not writing more clearly :-)
cheers,
Leo
Re: Release Management
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Leo Simons wrote:
> Release and build processes
>
> Hi gang,
>
> since I missed a lot of the initial talks, I'm writing this seperately. There
> are a lot of "gotchas" related to release management. The ASF has historically
> been real good at it and really lousy at creating a documented policy. Stuff
> like
>
> * There should be a documented and straightforward and automated way to
> re-generate any release or relase snapshot "n" years from now. All the
> artifacts for doing that should live in SVN. Eg we want to be able to do
>
> $ svn co http://.../tags/....
> $ cd ....
> $ sh release.sh
> $ wget http://www.apache.org/dist/harmony/..../.....tgz.sha1
> $ openssl dgst -sha1 -verify .....tgz.sha1 .....
> Verification OK
> $
>
> or get as close to something like that as possible.
So far, that's there, except for the zipping. The binaries for the
current snapshot are created from the ant build and zipped up. Tim will
add a 'dist' target when all is sorted.
>
> * Releases should be properly GPG-signed, with SHA1 digest provided as well,
> etc etc.
>
> There is documentation on release management somewhere on
>
> http://www.apache.org/dev/
>
> (sorry, no network as I type). There are incubation rules pertaining to
> publishing releases and/or snapshots somewhere on
>
> http://incubator.apache.org/
>
> I know I've previously written about this stuff to several mailing lists and
> several wiki pages, IIRC by head something like
>
> http://wiki.apache.org/excalibur/ReleaseManagement
>
> should still exist. (I think at some point about 20% of the files on
> www.apache.org/dist/ where owned by me and I was the biggest policy-breaker
> in terms of bad symlinks, messed up file permissions, missing GPG signatures
> so I *had* to figure out some "right way" to do stuff...I still haven't fixed
> all my problems there I believe...)
>
> The thing I just want to stress right now...
>
> **Do not take this stuff lightly.** Apache is one of the most trusted names in
> the world when it comes to distributing large amounts of quality software and we
> have a responsibility to keep up the standard. All contributors and committers
> should take some time to review these links and all the technical details
> related to building and publishing releases. It might also be a good idea to
> read eg dev@httpd.apache.org and look at their commit logs and the like to get
> a feeling for what a "mature" release management process looks like here at the
> ASF. It pays off bigtime to get a sound and solid release process in place
> ASAP. Eg the distro script for JCHEVM in etc/ is a good start.
>
> Its a good idea to tackle doing a release process incrementally, so by all means
> "just get started" and publish some of those snapshots. Just make sure we're
> complying with all the relevant policies (URLs above). I wish I had
> some time to commit to help out writing down some tips 'n tricks or better yet
> writing some scripts to help with this and getting a gump run going, but I don't
> think I have that time at the moment :-/.
That's what has been done. Everything has so far been marked 'snapshot'
and they aren't signed because they aren't a release.
geir
>
> Just some random rants, I'm sorry about not writing more clearly :-)
>
> cheers,
>
> Leo
>
>
Re: Release Management
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Leo Simons wrote:
> On Mon, Jan 16, 2006 at 03:26:35PM -0500, Geir Magnusson Jr wrote:
>> I'm familiar with all of this, Leo.
>
> Heh, I know *you* are :-). I saw questions, confusion, madness and mayhem
> all around so I wrote some words to help make others as familiar with this
> as you ;)
Fair enough. My plan was to be introducing information as things came
up, rather than just dump, but it's good for people to understand why I
was being so particular about process and form with this, I suppose.
geir
>
>> I noted to PMC that we will be doing build snapshots. These aren't
>> releases of any sort, but rather snapshots pre-built to make it easier
>> for people because of the toolchain difficulties that people still have.
>> These are clearly marked as snapshots.
>
> IIRC when Derby wanted to do the same there was lots of discussion. In terms
> of "get it right" I think there should still be all the disclaimers and stuff
> and blah blah blah :-)
>
> LSD
>
>
Re: Release Management
Posted by Leo Simons <ma...@leosimons.com>.
On Mon, Jan 16, 2006 at 03:26:35PM -0500, Geir Magnusson Jr wrote:
> I'm familiar with all of this, Leo.
Heh, I know *you* are :-). I saw questions, confusion, madness and mayhem
all around so I wrote some words to help make others as familiar with this
as you ;)
> I noted to PMC that we will be doing build snapshots. These aren't
> releases of any sort, but rather snapshots pre-built to make it easier
> for people because of the toolchain difficulties that people still have.
> These are clearly marked as snapshots.
IIRC when Derby wanted to do the same there was lots of discussion. In terms
of "get it right" I think there should still be all the disclaimers and stuff
and blah blah blah :-)
LSD
Re: Release Management
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I'm familiar with all of this, Leo.
I noted to PMC that we will be doing build snapshots. These aren't
releases of any sort, but rather snapshots pre-built to make it easier
for people because of the toolchain difficulties that people still have.
These are clearly marked as snapshots.
Thanks
geir
Leo Simons wrote:
> On Mon, Jan 16, 2006 at 11:53:58AM -0800, Leo Simons wrote:
>> (sorry, no network as I type). There are incubation rules pertaining to
>> publishing releases and/or snapshots somewhere on
>>
>> http://incubator.apache.org/
>
> http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>
> """
> As podlings are not yet fully accepted as part of the Apache Software Foundation, any software releases
> (including code held in publically available SVN) made by Podlings will not be endorsed by the ASF.
>
> However, as software releases are an important part of any software project, they are permitted in certain
> circumstances, as follows.
>
> Podlings in Incubation SHALL NOT perform any releases of software without the explicit approval of the Incubator
> PMC. Such approval SHALL be given only after the Incubator PMC has followed the process detailed in (Reference
> to Charter), and SHALL NOT occur until all source has been legally transferred to the ASF.
>
> Therefore, should a Podling decide it wishes to perform a release, the Podling SHALL formally request the
> Incubator PMC approve such a release. The request SHALL have the endorsement of the Mentor.
>
> Should the Incubator PMC, in accordance with (Reference to Charter) vote to approve the request, the Podling MAY
> perform the release under the following constraints :
>
> * the release archive MUST contain the word "incubating" in the filename; and
> * the release archive MUST contain an Incubation disclaimer (as described in the previous section), clearly
> visible in the main documentation or README file.
> """
>
> - LSD
>
>
Re: Release Management
Posted by Leo Simons <ma...@leosimons.com>.
On Mon, Jan 16, 2006 at 11:53:58AM -0800, Leo Simons wrote:
> (sorry, no network as I type). There are incubation rules pertaining to
> publishing releases and/or snapshots somewhere on
>
> http://incubator.apache.org/
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
"""
As podlings are not yet fully accepted as part of the Apache Software Foundation, any software releases
(including code held in publically available SVN) made by Podlings will not be endorsed by the ASF.
However, as software releases are an important part of any software project, they are permitted in certain
circumstances, as follows.
Podlings in Incubation SHALL NOT perform any releases of software without the explicit approval of the Incubator
PMC. Such approval SHALL be given only after the Incubator PMC has followed the process detailed in (Reference
to Charter), and SHALL NOT occur until all source has been legally transferred to the ASF.
Therefore, should a Podling decide it wishes to perform a release, the Podling SHALL formally request the
Incubator PMC approve such a release. The request SHALL have the endorsement of the Mentor.
Should the Incubator PMC, in accordance with (Reference to Charter) vote to approve the request, the Podling MAY
perform the release under the following constraints :
* the release archive MUST contain the word "incubating" in the filename; and
* the release archive MUST contain an Incubation disclaimer (as described in the previous section), clearly
visible in the main documentation or README file.
"""
- LSD