This page contains the current proposal for renewed JSPWiki versioning.

Rationale#

JSPWiki versioning has so far been based on the usual major.minor.revision scheme, in which the revision is updated every time any functionality-changing takes place. This includes essentially any changes to the codebase.

The good thing with this is that we can accurately pin-point to a revision and say "it was fixed in version 2.5.123". This is useful to developers, and it also gives an unique identity to every single build.

The bad thing is that it's difficult for people to report issues, or to keep track where things are going - we can sometimes even release multiple times per day, which in Apache terms is not a good thing. A "Release" has a very specific meaning, and it needs to go through all sorts of hoops before being approved.

Proposal#

This is a slightly reworked version of the previous version, which still had the even-odd alternation.

As of JSPWiki 3.0, we'll adopt a new versioning system:

major.minor.revision-identifier-build

Where

  • major = Major release, which breaks compatibility (binary or source) with previous versions.
  • minor = Minor update with new major functionality which does not break downwards compatibility (except in maybe minor ways). Even numbers are reserved for stable branches, odd numbers for unstable branches.
  • revision = Bug fixes or minor functionality updates. Forward and backward compatibility within the same major.minor revision is retained.
  • identifier = Identifies the type of this release. Following types are known:
    • svn = identifies the SVN trunk. No release gets this tag.
    • alpha = Release which has been tagged as "alpha" grade.
    • beta = Release which has been tagged as "beta" grade.
    • incubating = Release which has been released out of Apache Incubator
  • build = Build number. This must be incremented every time when a committer checks in code.

The progression#

Development process#

The "svn" tag always denotes unstable code from the branch. The version number always denotes which version this development is going to.

  • 3.0.0-svn-1 = "This is the first development build for 3.0.0"
  • 3.0.0-svn-2 = "This is the second development build for 3.0.0"
  • 3.0.1-svn-1 = "This is the first development build for 3.0.1"

etc.

Alpha/Beta process#

Once the code fulfils the release criteria (set for each version separately), the release manager declares an alpha or beta release (typically alpha for major releases, direct to beta on minor releases, sometimes even straight to a release candidate (for e.g. security fixes).

Release manager checks out the relevant branch, and modifies the Release file identifier to e.g. "beta". He then resets the build number to 1. That is, if 3.0.0-svn-123 is deemed to be releaseable, the next version would then be "3.0.0-beta-1".

The next version after this would be "3.0.0-svn-124", since only a release manager can tag a version "beta". Once development continues, the build number gets increased, until the RM can again release a beta version. This would then be called "3.0.0-beta-2".

Essentially this means that committers would just keep incrementing the "svn" build number.

Release process#

Once there is sufficient consensus (that is, all issues tagged for this release are fixed, there are no code contributions anymore accepted for a release, and nobody seems to be overly complaining about the quality of the betas), the release manager can call for a release.

If this is a major release (x.y), and the development is in the trunk, the RM will branch off a new SVN branch ("JSPWIKI_X_Y_BRANCH"), and create a new version in it - in this case "3.0.0". No markings, no extras. (Unless we're still in incubation, in which case it becomes "3.0.0-incubating".) This is known as the first release candidate.

If the development was already in a branch, a tag will be sufficient.

The RM will also tag this version as "jspwiki_x_y_z" (e.g. "jspwiki_3_0_0"), and prepare the release artifacts (signed source & binary zips) and makes them available. He then calls for a vote on the jspwiki-dev -mailing list, and this vote goes according to Apache process.

If there are major issues detected during the voting period or the vote does not pass, the development continues in the branch until issues are fixed. Once the vote is called again, the RM re-tags the version as "jspwiki_x_y_z" (moving the old tag).

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-6) was last changed on 30-Nov-2008 18:15 by Janne Jalkanen