Versioning, Tagging, and Branching
We generally use a triple version number, (a.b.c):
- The last number (c) is incremented by our bi-weekly release. Every module gets a new version, even the ones that did not change. When a prio 1 bug is fixed in a module, it gets released separately with an additional patch number (for example 22.214.171.124 for the first patch on the 1.0.20 release). In that case, the 1.0.20 tag is promoted to a branch (for the entire repo and not just the module). Changes on the branch are merged back into default.
- The second number (b) is incremented by milestones (roughly evey quarter, i.e., 4 times a year).
- The first number (a) will change probably only once a year or two years.
We use the Maven release plugin to perform our release. In the prepare phase, module version numbers are upgraded to the next version (1.0.19 -> 1.0.20 or -> 1.1 in case of a milestone release). In the perform phase, the modules are uploaded to a release repository at Sonatype. When we close the Sonatype release repository, the modules are synced to Maven central.
One trick we use with the Maven release repository is to use the local repository as developerConnection:
This way, you can manually push all the changes made in the version system. This prevents having to do a lot of cleanup after a failed release.
We currently maintain two repositories, "core" and "extra". Modules and suites are organized as if they were one repository. The difference is that an optional module in a core suite will be located in a different source repository.
Both repositories have their own update center module ("uc-core" module and the "uc-extra" module). The update centers point to a catalog.xml located on our server, with a major.milestone version in its path, which is currently:
This way we can maintain updates on the previous milestone version in the transition period. (And in general API's may only break backwards compatibility in a new milestone release.)
Since there will be third party modules depending on our core APIs, this transition period can take a few weeks.
To create the "catalog.xml", we currently have to perform quite a few manual tasks. We maintain a "modules-core" and "modules-extra" application module. Those have dependencies on all modules that should be released for that repository. We generate the catalog.xml by performing a
$mvn clean package -Pdeployment
Then we need to strip all NetBeans modules from the "catalog.xml" and cleanup the licenses section. After the cleanup, we upload the "catalog.xml" and "catalog.xml.gz" to our website.