You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@marmotta.apache.org by Sebastian Schaffert <se...@gmail.com> on 2013/03/22 11:53:04 UTC
Explaining the Apache Marmotta Release Process
Dear all,
since I am now repeating the whole process for the n-th time, I'd like to
give a more detailed explanation of the steps involved in releasing Apache
Marmotta and what happens when they are performed. I'll also add this
somewhere to the wiki if I find time.
Prerequisites:
- you need a PGP/GPG key
- you need the gpg-agent running (or otherwise you'll need to enter your
password about 160 times)
- you need the passwords for the Apache Maven repositories
(apache.releases.https, apache.snapshots.https) configured in your
settings.xml
- you need to configure GIT so the passwords for the upstream repository
need not be entered
Please be also aware of the following documentation on the Apache website:
- Check http://www.apache.org/dev/#releases
- Read http://www.apache.org/dev/release-publishing.html
- Read http://www.apache.org/dev/publishing-maven-artifacts.html
The whole release process is completely based on Maven and the "Maven
Release Plugin", i.e. I added all the necessary steps to a Maven profile
that can be used to run the release. Note however that this does not
release you from the burden of doing manual checking of the result
afterwards!
1. Check that system builds, carry out some automatic license checking
======================================================
Start with the latest snapshot build. Make sure your local GIT repository
is committed and in sync with the remote repository.
1a. do a mvn clean install
Do not skip tests. The purpose is to see if the build is working. If it is
not, it saves you a lot of trouble doing this easy Maven build. In any
later phase you might need to meddle with GIT, clean up repositories, or
worse.
1b. do a mvn apache-rat:check and possibly a mvn apache-rat:rat (creates a
html report in target/)
This will check if all files have appropriate license headers, except those
that have explicitly been included in the parent POM. If a file is excluded
in the parent POM, add a comment why this is done, so others can later see
the reasons. If the check fails, fix the affected source files, and start
over (don't forget to GIT commit and push).
2. Prepare the Release
=================
The Maven Release Plugin basically has two phases: preparation and the
actual release. The prepare phase will
- update all your POM files to the release version number (e.g.
3.0.0-incubating)
- run a complete build deploying to a local repository
- if successful, commit these changes to the GIT repository (by default
only local commit without a push)
- add to this commit the release tag in GIT (e.g. "3.0.0-incubating")
- update all your POM files to the next snapshot version number (e.g.
3.1.0-incubating-SNAPSHOT)
- commit these changes again to the GIT repository (again only local commit)
This means that after preparation, both your local working copy and your
local repository will already be the new snapshot version! To make it a bit
easier to undo such changes, I disabled the automatic GIT push to the
upstream GIT repository. Undoing changes in your local repository requires
only a bit of GIT meddling. Undoing changes in the remote repository is
simply impossible (and dangerous).
In the "prepare" phase, it is possible to do a dry run. Use this last
opportunity offered by the system to check if everything is ok:
mvn release:prepare -DreleaseVersion=3.0.0-incubating
-DdevelopmentVersion=3.1.0-incubating-SNAPSHOT -DautoVersionSubmodules=true
-DdryRun=true
This command will do all the steps of a normal release preparation except
running any automatic GIT commands. Can make your live a lot less
troublesome in case of errors.
If all goes well, do a "mvn release:clean" and then do the actual
preparation:
mvn release:prepare -DreleaseVersion=3.0.0-incubating
-DdevelopmentVersion=3.1.0-incubating-SNAPSHOT
3. Perform the Release
=================
The second step of the Maven Release Plugin is actually performing the
release. No dry-run is possible here, so failure is bad. Make sure you have
GPG agent running and all passwords configured properly. The phase will
carry out the following steps:
- check out from your GIT repository the commit that was tagged with the
release tag (e.g. "3.0.0-incubating")
- switch to this directory and run a complete build with the following
profiles activated: "marmotta-release,installer,sign"
The build will be completely clean and simulate the same environment that
any user will get who checks out the release tag for the first time on his
machine. The three release profiles together have been configured to carry
out the following steps:
- build and install all the project, with tests in the separate checkout
directory target/checkout
- do a last check with apache-rat:check to ensure the licenses are correct
- sign and deploy all Maven artifacts (with GPG signatures) to the
"staging" Apache Maven Repository
- build and sign all distribution assemblies (i.e. currently the -src,
-ldpath, -webapp, -installer assemblies)
- create a directory under ${root}/target/checkout/target with the name of
the release (e.g. 3.0.0-incubating)
- copy all distribution assemblies to this directory
- create a template VOTE email in ${root}/vote.txt
- print further instructions on stdout
Already quite cool, but a few manual steps are still remaining to finish
the release:
4. Upload Distribution Assemblies
=========================
First of all, check the distribution files in
target/checkout/target/3.0.0-incubating, especially regarding license
files, readme, and installability.
Distribution files are managed by a dedicated Subversion server. There are
two distribution directories in this subversion server that are interesting
for Apache Marmotta:
- https://dist.apache.org/repos/dist/dev/incubator/marmotta/ will contain
the distribution assemblies for the voting process on the mailinglist
- https://dist.apache.org/repos/dist/release/incubator/marmotta/ will
contain the distribution assemblies after the voting process has been
finished with positive result
For continuing with the release, please check out both Subversion
repositories, e.g. with:
svn co https://dist.apache.org/repos/dist/dev/incubator/marmotta/marmotta-releases-voting
svn co https://dist.apache.org/repos/dist/release/incubator/marmotta/marmotta-releases-final
Now copy over the directory containing the distribution assemblies created
by the build process (see above) to the "voting" working copy:
cp -r <MARMOTTA-WORKING-COPY>/target/checkout/target/3.0.0-incubating
<VOTING-WORKING-COPY>
add the resulting directory to subversion:
svn add 3.0.0-incubating
svn commit -m "new Apache Marmotta release candidate"
This will upload the release artifacts to the subversion server.
5. Close Staging Repository
====================
The Maven artifacts are uploaded to a "staging" repository on the ASF Maven
Nexus. Staging repositories are separate spaces meant for checking releases
before really distributing them. To be able to access this staging
repository, it first needs to be closed, so
- go to https://repository.apache.org and log in with your Apache ID
- select "Staging Repositories" on the left, it should display the Marmotta
Staging Repository
- check the Marmotta repository (checkbox) and click on "Close" in the menu
above; provide a sensible commit message!
Closing the repository will carry out some simple consistency and error
checks, specifically it will check GPG signatures.
While in Nexus, remember the URL of the staging repository by clicking on
its name. You will need it later :-)
(in my current case this is
https://repository.apache.org/content/repositories/orgapachemarmotta-013/)
6. Push Local GIT to Upstream
=======================
Changes have been performed in your local GIT repository, but since we
disabled this feature for security reasons, they are not automatically
pushed to the upstream repository. So don't forget to do a
git push
;-)
7. Send VOTE E-Mail
================
The final step in the release process is to send out the VOTE E-Mail to the
Marmotta Developer mailinglist. A template for this mail has been prepared
for you at
target/checkout/target/vote.txt
This template needs to be completed manually by some information.
Particularly, you need to
- write a bit of introduction
- insert the correct URL of the Maven Staging Repository (you copied it in
step 5)
The voting period is 72 hours. While in incubation, when we have concluded
a vote on the developer mailinglist, we also need to run an additional vote
on the incubator general mailinglist, so the whole process will be 144
hours (or 6 days).
Hope this helps a bit understanding what I have been doing the last week :)
Greetings,
Sebastian
Re: Explaining the Apache Marmotta Release Process
Posted by Sergio Fernández <wi...@apache.org>.
I think we must have the tag created, then is easier to check. And git
allow to remove tags. So definitely the order of steps 6 and 7 is right.
On 22/03/13 18:04, Sebastian Schaffert wrote:
> Hi Andy,
>
> this is only possible if I do "Step 6", i.e. push my local repository to
> the upstream repository - this is what the discussion was about. :-)
>
> Greetings,
>
> Sebastian
>
> 2013/3/22 Andy Seaborne<an...@apache.org>
>
>> On 22/03/13 15:56, Jakob Frank wrote:
>>
>>> Not sure whether this is possible:
>>>
>>> As Andy said [1] one of the checks to do before voting should be:
>>>
>>>> if there is a tag in the SCM, does it contain reproduceable sources?
>>>>
>>>
>> It is possible:
>>
>> git checkout 3.0.0-incubating
>> mvn clean install
>>
>> Andy
>>
>>
>>
>>> Best,
>>> Jakob
>>>
>>> [1]<
>>> https://mail-archives.apache.**org/mod_mbox/incubator-**
>>> marmotta-dev/201303.mbox/%**3C5146D72F.4000703%40apache.**org%3E<https://mail-archives.apache.org/mod_mbox/incubator-marmotta-dev/201303.mbox/%3C5146D72F.4000703%40apache.org%3E>
>>>
>>>>
>>>>
>>> On 22 March 2013 15:13, Fabian Christ<ch...@googlemail.com>
>>> wrote:
>>>
>>> 2013/3/22 Sebastian Schaffert<sebastian.schaffert@gmail.com**>:
>>>>
>>>>> 6. Push Local GIT to Upstream
>>>>> =======================
>>>>>
>>>>
>>>> Great docu! Just a question out of interest. Should step 6 be made
>>>> before the vote has passed? IIUC step 6 publishes the updated versions
>>>> to the remote server. So after this step the version numbers are
>>>> increased for everyone. Now, imagine the vote will not pass. How will
>>>> you decrease the version numbers to revert the change (rollback the
>>>> release)?
>>>>
>>>> With SVN I always have the problem that the versions are updated
>>>> before the vote has passed. That makes a rollback a bit tricky and
>>>> error prone. With GIT it seems that you have the tool that would make
>>>> it possible to wait for updating the versions after the vote has
>>>> really passed. Just move step 6 after step 7.
>>>>
>>>> Best,
>>>> - Fabian
>>>>
>>>>
>>>> --
>>>> Fabian
>>>> http://twitter.com/fctwitt
>>>>
>>>>
>>>
>>
>
--
Sergio Fernández
Re: Explaining the Apache Marmotta Release Process
Posted by Andy Seaborne <an...@apache.org>.
On 22/03/13 17:04, Sebastian Schaffert wrote:
> Hi Andy,
>
> this is only possible if I do "Step 6", i.e. push my local repository to
> the upstream repository - this is what the discussion was about. :-)
Yes - Jakob was referring to a check done by the reviewers and it's an
important check.
Andy
>
> Greetings,
>
> Sebastian
>
> 2013/3/22 Andy Seaborne <an...@apache.org>
>
>> On 22/03/13 15:56, Jakob Frank wrote:
>>So ... do you expect votes to normally pass or normally fail :-)
>>> Not sure whether this is possible:
>>>
>>> As Andy said [1] one of the checks to do before voting should be:
>>>
>>>> if there is a tag in the SCM, does it contain reproduceable sources?
>>>>
>>>
>> It is possible:
>>
>> git checkout 3.0.0-incubating
>> mvn clean install
>>
>> Andy
>>
>>
>>
>>> Best,
>>> Jakob
>>>
>>> [1] <
>>> https://mail-archives.apache.**org/mod_mbox/incubator-**
>>> marmotta-dev/201303.mbox/%**3C5146D72F.4000703%40apache.**org%3E<https://mail-archives.apache.org/mod_mbox/incubator-marmotta-dev/201303.mbox/%3C5146D72F.4000703%40apache.org%3E>
>>>
>>>>
>>>>
>>> On 22 March 2013 15:13, Fabian Christ <ch...@googlemail.com>
>>> wrote:
>>>
>>> 2013/3/22 Sebastian Schaffert <sebastian.schaffert@gmail.com**>:
>>>>
>>>>> 6. Push Local GIT to Upstream
>>>>> =======================
>>>>>
>>>>
>>>> Great docu! Just a question out of interest. Should step 6 be made
>>>> before the vote has passed? IIUC step 6 publishes the updated versions
>>>> to the remote server. So after this step the version numbers are
>>>> increased for everyone. Now, imagine the vote will not pass. How will
>>>> you decrease the version numbers to revert the change (rollback the
>>>> release)?
>>>>
>>>> With SVN I always have the problem that the versions are updated
>>>> before the vote has passed. That makes a rollback a bit tricky and
>>>> error prone. With GIT it seems that you have the tool that would make
>>>> it possible to wait for updating the versions after the vote has
>>>> really passed. Just move step 6 after step 7.
>>>>
>>>> Best,
>>>> - Fabian
>>>>
>>>>
>>>> --
>>>> Fabian
>>>> http://twitter.com/fctwitt
>>>>
>>>>
>>>
>>
>
Re: Explaining the Apache Marmotta Release Process
Posted by Sebastian Schaffert <se...@gmail.com>.
Hi Andy,
this is only possible if I do "Step 6", i.e. push my local repository to
the upstream repository - this is what the discussion was about. :-)
Greetings,
Sebastian
2013/3/22 Andy Seaborne <an...@apache.org>
> On 22/03/13 15:56, Jakob Frank wrote:
>
>> Not sure whether this is possible:
>>
>> As Andy said [1] one of the checks to do before voting should be:
>>
>>> if there is a tag in the SCM, does it contain reproduceable sources?
>>>
>>
> It is possible:
>
> git checkout 3.0.0-incubating
> mvn clean install
>
> Andy
>
>
>
>> Best,
>> Jakob
>>
>> [1] <
>> https://mail-archives.apache.**org/mod_mbox/incubator-**
>> marmotta-dev/201303.mbox/%**3C5146D72F.4000703%40apache.**org%3E<https://mail-archives.apache.org/mod_mbox/incubator-marmotta-dev/201303.mbox/%3C5146D72F.4000703%40apache.org%3E>
>>
>>>
>>>
>> On 22 March 2013 15:13, Fabian Christ <ch...@googlemail.com>
>> wrote:
>>
>> 2013/3/22 Sebastian Schaffert <sebastian.schaffert@gmail.com**>:
>>>
>>>> 6. Push Local GIT to Upstream
>>>> =======================
>>>>
>>>
>>> Great docu! Just a question out of interest. Should step 6 be made
>>> before the vote has passed? IIUC step 6 publishes the updated versions
>>> to the remote server. So after this step the version numbers are
>>> increased for everyone. Now, imagine the vote will not pass. How will
>>> you decrease the version numbers to revert the change (rollback the
>>> release)?
>>>
>>> With SVN I always have the problem that the versions are updated
>>> before the vote has passed. That makes a rollback a bit tricky and
>>> error prone. With GIT it seems that you have the tool that would make
>>> it possible to wait for updating the versions after the vote has
>>> really passed. Just move step 6 after step 7.
>>>
>>> Best,
>>> - Fabian
>>>
>>>
>>> --
>>> Fabian
>>> http://twitter.com/fctwitt
>>>
>>>
>>
>
Re: Explaining the Apache Marmotta Release Process
Posted by Andy Seaborne <an...@apache.org>.
On 22/03/13 15:56, Jakob Frank wrote:
> Not sure whether this is possible:
>
> As Andy said [1] one of the checks to do before voting should be:
>> if there is a tag in the SCM, does it contain reproduceable sources?
It is possible:
git checkout 3.0.0-incubating
mvn clean install
Andy
>
> Best,
> Jakob
>
> [1] <
> https://mail-archives.apache.org/mod_mbox/incubator-marmotta-dev/201303.mbox/%3C5146D72F.4000703%40apache.org%3E
>>
>
> On 22 March 2013 15:13, Fabian Christ <ch...@googlemail.com> wrote:
>
>> 2013/3/22 Sebastian Schaffert <se...@gmail.com>:
>>> 6. Push Local GIT to Upstream
>>> =======================
>>
>> Great docu! Just a question out of interest. Should step 6 be made
>> before the vote has passed? IIUC step 6 publishes the updated versions
>> to the remote server. So after this step the version numbers are
>> increased for everyone. Now, imagine the vote will not pass. How will
>> you decrease the version numbers to revert the change (rollback the
>> release)?
>>
>> With SVN I always have the problem that the versions are updated
>> before the vote has passed. That makes a rollback a bit tricky and
>> error prone. With GIT it seems that you have the tool that would make
>> it possible to wait for updating the versions after the vote has
>> really passed. Just move step 6 after step 7.
>>
>> Best,
>> - Fabian
>>
>>
>> --
>> Fabian
>> http://twitter.com/fctwitt
>>
>
Re: Explaining the Apache Marmotta Release Process
Posted by Sergio Fernández <wi...@apache.org>.
Hi,
On 24/03/13 10:28, Fabian Christ wrote:
> But it assumes that all artifacts have the same version, right? If you
> have very different versions in your released artifacts it gets a bit
> more complicated.
Right. That's one of the reasons because in Marmotta we decided to adopt
a homogeneous release cycle for all artifacts.
But I guess the release plugin won't work fine on projects with
different versioning schemas per module, as happens in Stanbol. For
that, maybe you could take a look to the versions plugin:
http://mojo.codehaus.org/versions-maven-plugin/
Cheers,
--
Sergio Fernández
Re: Explaining the Apache Marmotta Release Process
Posted by Fabian Christ <ch...@googlemail.com>.
2013/3/22 Sebastian Schaffert <se...@gmail.com>:
> mvn --batch-mode
> release:update-versions -DdevelopmentVersion=3.0.0-incubating-SNAPSHOT
> -DautoVersionSubmodules=true
That's a nice way. Did not use that kind of command before.
But it assumes that all artifacts have the same version, right? If you
have very different versions in your released artifacts it gets a bit
more complicated. Anyway, thanks for the insight and I will try to
adopt this for Stanbol ;)
--
Fabian
http://twitter.com/fctwitt
Re: Explaining the Apache Marmotta Release Process
Posted by Sebastian Schaffert <se...@gmail.com>.
Small bug in last mail :)
2013/3/22 Sebastian Schaffert <se...@gmail.com>
> Hi Fabian and Jakob,
>
> as Jakob says, it is necessary to have the release candidate version and
> tag pushed upstream, because otherwise other people are not able to check
> the release.
>
> Since I also did this revert already twice, here is the process (it is
> simple and harmless):
> - remove the release tag from GIT (this is possible even for a remote
> repository)
>
see http://nathanhoad.net/how-to-delete-a-remote-git-tag
> - update the version number in all POM files back to the previous snapshot
> version with the following command:
>
> mvn --batch-mode
> release:update-versions -DdevelopmentVersion=3.1.0-incubating-SNAPSHOT
> -DautoVersionSubmodules=true
>
sorry, that should be
mvn --batch-mode
release:update-versions -DdevelopmentVersion=3.0.0-incubating-SNAPSHOT
-DautoVersionSubmodules=true
i.e. the previous version :)
>
> - commit again and push
>
> The advantage of this approach is that in this case the whole process is
> documented in the GIT repository. Reverting in GIT is IMO only necessary in
> case the release process itself fails (which can happen e.g. if you enter a
> wrong password or some other kind of system failure).
>
> ;-)
>
> Greetings,
>
> Sebastian
>
>
> 2013/3/22 Fabian Christ <ch...@googlemail.com>
>
>> 2013/3/22 Jakob Frank <ja...@apache.org>:
>> > Not sure whether this is possible:
>> >
>> > As Andy said [1] one of the checks to do before voting should be:
>> >> if there is a tag in the SCM, does it contain reproduceable sources?
>>
>> So is Step 6 for publishing the tag or for publishing the increased
>> development versions of the artifacts - or both?
>>
>>
>> --
>> Fabian
>> http://twitter.com/fctwitt
>>
>
>
Re: Explaining the Apache Marmotta Release Process
Posted by Sebastian Schaffert <se...@gmail.com>.
Hi Fabian and Jakob,
as Jakob says, it is necessary to have the release candidate version and
tag pushed upstream, because otherwise other people are not able to check
the release.
Since I also did this revert already twice, here is the process (it is
simple and harmless):
- remove the release tag from GIT (this is possible even for a remote
repository)
- update the version number in all POM files back to the previous snapshot
version with the following command:
mvn --batch-mode
release:update-versions -DdevelopmentVersion=3.1.0-incubating-SNAPSHOT
-DautoVersionSubmodules=true
- commit again and push
The advantage of this approach is that in this case the whole process is
documented in the GIT repository. Reverting in GIT is IMO only necessary in
case the release process itself fails (which can happen e.g. if you enter a
wrong password or some other kind of system failure).
;-)
Greetings,
Sebastian
2013/3/22 Fabian Christ <ch...@googlemail.com>
> 2013/3/22 Jakob Frank <ja...@apache.org>:
> > Not sure whether this is possible:
> >
> > As Andy said [1] one of the checks to do before voting should be:
> >> if there is a tag in the SCM, does it contain reproduceable sources?
>
> So is Step 6 for publishing the tag or for publishing the increased
> development versions of the artifacts - or both?
>
>
> --
> Fabian
> http://twitter.com/fctwitt
>
Re: Explaining the Apache Marmotta Release Process
Posted by Fabian Christ <ch...@googlemail.com>.
2013/3/22 Jakob Frank <ja...@apache.org>:
> Not sure whether this is possible:
>
> As Andy said [1] one of the checks to do before voting should be:
>> if there is a tag in the SCM, does it contain reproduceable sources?
So is Step 6 for publishing the tag or for publishing the increased
development versions of the artifacts - or both?
--
Fabian
http://twitter.com/fctwitt
Re: Explaining the Apache Marmotta Release Process
Posted by Jakob Frank <ja...@apache.org>.
Not sure whether this is possible:
As Andy said [1] one of the checks to do before voting should be:
> if there is a tag in the SCM, does it contain reproduceable sources?
Best,
Jakob
[1] <
https://mail-archives.apache.org/mod_mbox/incubator-marmotta-dev/201303.mbox/%3C5146D72F.4000703%40apache.org%3E
>
On 22 March 2013 15:13, Fabian Christ <ch...@googlemail.com> wrote:
> 2013/3/22 Sebastian Schaffert <se...@gmail.com>:
> > 6. Push Local GIT to Upstream
> > =======================
>
> Great docu! Just a question out of interest. Should step 6 be made
> before the vote has passed? IIUC step 6 publishes the updated versions
> to the remote server. So after this step the version numbers are
> increased for everyone. Now, imagine the vote will not pass. How will
> you decrease the version numbers to revert the change (rollback the
> release)?
>
> With SVN I always have the problem that the versions are updated
> before the vote has passed. That makes a rollback a bit tricky and
> error prone. With GIT it seems that you have the tool that would make
> it possible to wait for updating the versions after the vote has
> really passed. Just move step 6 after step 7.
>
> Best,
> - Fabian
>
>
> --
> Fabian
> http://twitter.com/fctwitt
>
Re: Explaining the Apache Marmotta Release Process
Posted by Andy Seaborne <an...@apache.org>.
On 22/03/13 14:13, Fabian Christ wrote:
> 2013/3/22 Sebastian Schaffert <se...@gmail.com>:
>> 6. Push Local GIT to Upstream
>> =======================
>
> Great docu! Just a question out of interest. Should step 6 be made
> before the vote has passed? IIUC step 6 publishes the updated versions
> to the remote server. So after this step the version numbers are
> increased for everyone. Now, imagine the vote will not pass. How will
> you decrease the version numbers to revert the change (rollback the
> release)?
>
> With SVN I always have the problem that the versions are updated
> before the vote has passed. That makes a rollback a bit tricky and
> error prone. With GIT it seems that you have the tool that would make
> it possible to wait for updating the versions after the vote has
> really passed. Just move step 6 after step 7.
>
> Best,
> - Fabian
It's a balance and I don't think there can be a perfect answer.
It is important to push the release tag.
Setting active codebase to the new version enables people to keep
developing while the vote is taking place.
Andy
Re: Explaining the Apache Marmotta Release Process
Posted by Fabian Christ <ch...@googlemail.com>.
2013/3/22 Sebastian Schaffert <se...@gmail.com>:
> 6. Push Local GIT to Upstream
> =======================
Great docu! Just a question out of interest. Should step 6 be made
before the vote has passed? IIUC step 6 publishes the updated versions
to the remote server. So after this step the version numbers are
increased for everyone. Now, imagine the vote will not pass. How will
you decrease the version numbers to revert the change (rollback the
release)?
With SVN I always have the problem that the versions are updated
before the vote has passed. That makes a rollback a bit tricky and
error prone. With GIT it seems that you have the tool that would make
it possible to wait for updating the versions after the vote has
really passed. Just move step 6 after step 7.
Best,
- Fabian
--
Fabian
http://twitter.com/fctwitt
Re: Explaining the Apache Marmotta Release Process
Posted by Sergio Fernández <wi...@apache.org>.
Hi,
On 22/03/13 11:53, Sebastian Schaffert wrote:
> since I am now repeating the whole process for the n-th time, I'd like to
> give a more detailed explanation of the steps involved in releasing Apache
> Marmotta and what happens when they are performed. I'll also add this
> somewhere to the wiki if I find time.
Extremely good documentation of the whole process!
I've just added it to the wiki:
http://wiki.apache.org/marmotta/ReleaseProcess
These days we learned a lot...
--
Sergio Fernández