Update documentation for the new release process

Reopening as I don't think the docs is complete. For example, it does not mention the staging process which we now use.
Also, I'm wondering how we are going to handle the cargo-parent. Are we to release that first (and wait for it to get to central) before releasing the other parts? If we don't, we'll include the cargo-parent in the staging and then we need to update settings.xml so that it can be found when building the rest.

What is a staging process?

I think, We are going to handle CARGO-parent (and all other CARGO modules, by the way) like before: since the released versions of artifacts are present on the developer's machine, everything should compile successfully. Maven central will get them rapidly, but meanwhile weird things wilk sure happen. CI will probably not be very happy.

The alternative is to wait for the Maven central repo to get the artifacts and then release each submodule. That might be time consuming.

Now when we are using the Nexus instance, the release will be deployed to a so-called staging repository first. We can then verify the release (there are also some automatic checks being done) before we promote it. When it has been promoted, it will be added to the Codehaus release repo and synced to central. The steps are described Codehaus Maven Repository Usage Guide (see link in this jira's description). There is also more details regarding Nexus Staging in the Nexus Book: http://www.sonatype.com/books/nexus-book/reference/staging.html
This will allow us to verify a release (within the Cargo team) before we actually promote it. Very handy. We just need to discuss how we are to do this (or if we are not).

Aaahhh ok..

How does staging work? Do I just tag a version, say, 1.0.3, it will be tagged in the SVN but appear in staging; and if we see it has issues we fix them and tag again 1.0.3?

Yes, that would be the standard way. How we tag and handle scm is up to us to decide. If we want to redo the release, we could either remove the tag in svn or we could use a new tag (like 1.0.3-build2 or whatever). For us, I think we should just remove the old tag, but for enterprises they often want to keep all tags (for testing history).

I've just managed to release the parent and completed documentation.

Once the new parent pom makes it into the central, I will also tag resources, core and and extensions.

Why are you releasing the parent in advance? I suggest we do one staged release for everything.

I still don't think the release process docs are good enough. It should explain the staging in more details. Especially, it should explain that there should be one staging for the entire Cargo release. Also, I'd like a step where all devs get the opportunity to verify the staged release. This would ensure that it works as expected.

Please see my e-mail on the dev list, deferring the good documentation to 1.0.4.

I've changed part of the documentation, reorganized it and added some basic rules (like "wait 72 hours between staging and release for people to comment)

I did some fine tuning the other day to correctly reflect that the three main code trunks are released/staged together.
This ticket should be fine to close now.

Finished