Introduction

This page is describes how to cut an ApacheDS release along with all it's dependent subprojects: daemon, shared and apacheds proper. A release is more involved than simply tagging a version and add news on the front page. It is rather involved. That is why we have added this page, so anyone can follow this stepwise process to release successfully.

Release Approval process

The release process is clear however the approval process has been put under some scrutiny recently. Some of us feel the candidate installers and jars should be made available before voting on whether or not to release. Today we simply discuss
the readiness to release and perform some tests then conduct a standard vote. As we refine this process this page will be
updated to reflect our progress.

Defining a candidate

The first thing is to have a clear candidate. We should not have any bugs remaining assigned to the current version, and all the important features should be present, and tested. Integration tests should work, on more than one system. At this point, it's good to ask other committers to check this.

Following a roadmap

This candidate is also the result of a roadmap being fulfilled. If we don't have a roadmpa for a version, we don't know when to release a version ! We are lucky to have more than one roadmap, so we can deliver versions on a reasonnable timeframe (every 3 months, average). That also means "don't overload a roadma". It's better to deliver less features but more often.

Reaching a consensus

At some point in the developement process, the committers think that the version is ready for release. There are no indicators, but more or less a gathered 'feeling' that the version is ok. Generrally speaking, we still have bugs. The idea is to list all the remaining bugs, and select which ones of them should be fixed, and which others should be postponed to a later version.

When every committer thinks that the parts they are working one are ok, or could be postponed to the next version, then we can start the release process

Fixing the last bugs, code freeze

There are still bugs. It's time to ficx them all. No known bug should remain for the version we are delivering, they must be postponed to the next version

Here, we should distinguish between stable versions and unstable versions. Stable versions should not contain bugs, or the related features should be removed from the version. Unstable version may contain minor bugs, assuming that their list is added in a specific file ("Known problems")

At this point, the code has been frozen : no more new features.

VSLDAP

It's a good step to check that VSLDAP is still happy with the current version. If not, we should fix the failing tests. If the version is supposed to be stable, then the certification must be validated by OpenGroup. As it can take a while, prliminary tests should be run one month before the version cosure. The good point is that we will have release candidates, so VSLDAP certification should start with RC1. No stable version should be released without being certified by OpenGroup.

Voting the version

It's time for a vote. When the vote is launched, the code should merely not be changed. This is a 72 h period of time, and if a clear bug suddenly appears, and can be fixed quickly, then it's ok. If the bug is nasty, and takes more than a few hours to be fixed, then the vote should be re-issued (IMHO).

When the vote is closed (no veto), the release itself can be processed.

h1; Action !
Here are the step to follow during the branching

(1) branch
(2) bump up versions from SNAPSHOT to next releases (1.0.2)
(3) check that server-tools MANIFEST is properly updated to use the right versions in the jar manifest
elecharny (2) has been done
aok (4) check that the archetype poms have been updated with the latest dependencies (under resources directories)
aok (5) make sure no SNAPSHOT jars are used in all pom.xml files
elecharny (4) and (5) done
aok (6) cd into server-installers and make sure that the pom.xml there references the correct paths to svn sources in this branch
aok this is for generating sources and doco
aok in the installers
aok (7) build the installers for all platforms and test the generated installers (kick the tires)
aok sorry forgot one
aok (5.5) tag this branch into apacheds/releases and shared/releases
elecharny we have to be carefull, because we will have 4 branches
elecharny - apacheds,
elecharny - shared
aok in (6) make sure the svn paths point to the apacheds/release
elecharny - dameon
aok yep
elecharny and the TLP
elecharny ok, I will feed a confleunce page with all those
aok basically you know the code in daemon plugin that svn exports the ADS sources?
aok there is a line in the POM that contqains the svn URL to export
aok fuck fuck
aok I messed up again
elecharny yeah, I remember now
aok ok claer your plate now
aok starting after (5) now
elecharny ok, have a dinner,
elecharny I gonna have my post-dinner evacuation,
elecharny and we will met in half an maven
aok haha go ahead I will document it now
aok while you shit
elecharny document my maven ???
aok (6) change the URL in the server-installers/pom.xml to point to the future svn url for the release tag
elecharny have you a 32" screen ?
aok hahaha
aok damn man
aok so for example the URL will point to ....apacheds/releases/1.0.2
aok (7) tag the release
aok (8) generate the installers and test
aok (9) test the installers (kick the tires) ... check apacheds-tools and startup scripts
aok if anything fails delete the tag and start all over on #6 after fixing the breakage
aok (10) deploy the jars to the production maven repo (mvn deploy)
aok can be done in the pre-release branch
aok (11) delete pre-release branch
aok (12) generate asc files (signatures) for all the jars and pom files deployed to the remote repository
aok for 12 what I do is tar copy all the files under org/apache/directory on people.apache.org
aok into my home directory. Then I delete all the old revisions that were released. I remove the md5 and the sha1 files but not the pom files or the other maven meta files.
aok Then I tar this and push it to my home machine.
aok After doing this I generate the asc signature files for these jars and pom files.
aok Then I delete all the pom files and the jars on my home machine
aok then I tar up all the asc files
aok and scp -r them back to where they need to be on the remote repository
aok MAKE SURE YOU BACKUP THE REMOTE REPO FOR DIRECTORY BEFORE YOU START
aok this way the asc files are in all the artifact directories
aok Use Trustin's sign.sh file to do this.
aok (13) For all installers generate the asc, md5, and sha1 files for them
aok (14) I used to use a hacked form of this sign.sh script to generate these md5 and sha1 files on my ubuntu box
aok (15) deploy these files and jars to the dist area which is mirrored for the installers
aok (16) sit back and have a beer
aok (17) make sure you do a chmod -R g+w on all the files you mess wit
aok s/files/directories/
aok (18) take another maven

Creating a temporary branch for the release

Better than taging the trunk, creating a branch where all the last modification will be done is the way to go. 4 elements must be copied in the branch :

• apacheds
• shared
• daemon
• apacheds with dependencies

Here are the commands :

svn copy https://svn.apache.org/repos/asf/directory/apacheds/trunk https://svn.apache.org/repos/asf/directory/apacheds/branches/x.y.z-pre-release
  -m "<message>"
svn copy https://svn.apache.org/repos/asf/directory/shared/trunk https://svn.apache.org/repos/asf/directory/shared/branches/x.y.z-pre-release
  -m "<message>"
svn copy https://svn.apache.org/repos/asf/directory/daemon/trunk https://svn.apache.org/repos/asf/directory/daemon/branches/x.y.z-pre-release
  -m "<message>"
svn copy https://svn.apache.org/repos/asf/directory/apacheds/trunk-with-dependencies
  https://svn.apache.org/repos/asf/directory/apacheds/branches/x.y.z-with-deps-pre-release
  -m "<message>"

We should also copy the commons-tlp files into apacheds-with-dependencies. They contain the top level scripts and pom.xml.

Checking the manifest, and mandatory files

We should control that all the manifest files are correct, and that the NOTICES.txt, README.txt etc. are correct. Here is the list of files to check :

• apacheds/server-installers/README.txt
  <todo: add files>

Build the installers

The installers for every OS must be built before tagging. When done, a last verification should be done by other committers, just in case.

Before building the installers, something should be changed in the apacheds/server-installers/pom.xml : there is a svn copy that takes file from trunk. It should be changed so that the files are taken from the branches we just created. At the end of the preparation, before tagging the release, we should just modify thise svn copy to point to the tag we will set.

Tagging the code

Ok, now, it's time to tag the code. With SVN, it's just a matter of copying the trunk to releases space, with a new name (the version : x.y.z). We can have three kind of versions :

• X-versions : major releases (the architecture may have changed a lot)
• Y-versions : minor releases (the architecture does not change, but some new features are addded)
• Z-versions : bug fixes

(The X/Y/Z-versions are related to the version numbering : ads-x.y.z ...)

Sign the packages

All the packages must be signed, before being deployed to the world.

Deploying the packages

Time to deploy and for the new version to hit the world ! Packages should be deployed to the apache download site, and each jar must be deployed to the maven repository.

Post release actions

Some more tasks must be done after the release has been issued.

Bumping the trunk version

Now, the trunk's projects should be upgraded. If the tagged version was X.Y.Z, then all the pom.xml files should refer to X.Y.(Z+1)-SNAPSHOT. Also note that we have not only apacheds as a project, but shared and triplesec. Each of these project should be updated.

Press Release

one day after the release is ok, we should inform the world about it. The bare minimum is a news added on our front site, and a mail to the users and dev mailing list. But we should also post a mail to apache news mailing list, and also to apache PR peeps. Announcment to TheServerSide, InfoQ, etc are also valuable.