Version Names

  • LTS Release: This is the most stable version and is what we recommend to use in production.
  • Stable Release: This is the version recommended if you wish to try out the new features from the current Cycle (see below for an explanation of what a Cycle is). It's possible to use those in production .
  • Unstable Release: This is the version to use if you want to test the really latest feature and provide feedback to the XWiki development team and help us stabilize the version. We don't recommend that you use these in production.

Version Types

Starting with XWiki 8.4 we have shortened our releases from 3 months to 1 months and thus we're dropping milestones by going directly to RC1

General format: Major.Minor[.Bugfix|-rc-number|-SNAPSHOT]


  • XWiki Enterprise 2.4.2: Bugfix release
  • XWiki Enterprise 2.7-rc-1: Release Candidate release
  • XWiki Enterprise 3.0-SNAPSHOT: Snapshot release


  • Major Releases (2.x, 3.x): Start of a new Development Cycle. Can contain non-backward compatible changes compared with the previous Cycle. 
  • Minor Releases (x.5, x.6): Mostly backward compatible from the user perspective. Can introduce new features provided they don't introduce non backward compatible changes from a user perspective. From time to time we allow some non backward compatible API changes too, following our deprecation strategy. It's recommended for users to upgrade and follow minor releases since this it's much easier to regularly upgrade than done a large upgrade spanning several minors. Should check Release Notes in case some non-backward compatible changes are introduced (on the API side).
  • Bugfix Releases (x.y.1, x.y.2): Contains only bug fixes and is 100% backward compatible. It's always recommended to upgrade as soon as possible since the bug fixes can contain security fixes.
  • Release Candidate Releases (a.k.a RC Releases, x.y-rc-1, x.y-rc-2)): Candidates for the Minor release. We usually have 1 or 2 before the Minor release. A RC means that we consider the version to be releasable as a Minor version but we want a last round of testing from the community and users before we perform the Minor release.
  • Snapshot Releases (continuous x.y-SNAPSHOT, or timestamped x.y-20110131.125707-122, or revision numbered x.y-SNAPSHOT.34017): Snapshots builds happen every time there's a code commit and are performed by our Continuous Integration tool. It's not recommended to use these, and especially not in production. However, these releases are useful to verify for example that a bugfix is valid or to test some newly introduced feature and provide feedback for it. We are always in need of feedback and thus would like to have the maximum number of users try out our snapshots builds and let us now how they perform. Users can, of course, build their own version from the source.

Release Cycles and Release Strategy

  • We have a notion of Release Cycles which corresponds to Major Releases

    The rationale for doing Major Releases:

    • It's a way to mark progress to the outside world and to be able to do open source marketing
    • It's a milestone in the project's life and it feels good to do it. It makes us developers feel proud of our achievements too.
    • It allows us to move forward since it's a good time to think back about what the xwiki project is and where it wants to go
    • A release cycle means all the release of the type X.N where X is the major and represent the cycle (and N is a non constrained number 0 <= N < infinity)
    • Duration: 11 minor releases (e.g. N.0 till N.10). That's 1 year since each minor release takes 1 month and we're leaving some margins (1 month) for delays, bug fix releases, etc (see below)

      Note: The rule about 11 minor releases is important for several reasons:

      • It implements timeboxing, our core tenet regarding releases
      • It allows us to not have to rediscuss when is the major going to happen every time
      • It allows us to know well in advance when the major release is going to happen and thus to adjust our commits during the whole cycle
      • It prevents "featuritis"
  • When we release the last minor of the cycle we announce it:
    • Send mail mentioning that the cycle is over and that version X.N is the last minor release of that cycle (but there can still be bugfix releases: X.N.P)
    • In that mail, explain all the major features that were implemented during that release cycle (make a special Release Notes for a Cycle)
  • For minor releases we have the following release strategy (1 month total):
    • a 3 weeks release cycles till the RC
    • a 1 week release cycles till the final versions

We're doing monthly releases for the following reasons:

  • Be able to stabilize our CI builds faster (reduce release time means less changes which means less stabilization required)
  • Be able to get our changes faster to our users. Importantly, bugfixes are released faster to users. Note: it’s not because we release faster that our users have to upgrade as fast. They can skip some versions if they want/need.
  • Be able to get more feedback more quickly from users. Users are testing only final versions. They’re not testing milestones or RCs. Thus with more final releases we should find out about problems (if any) faster and be able to get them to our users faster. We can do this now because we have better upgrade tools (with the Distribution Wizard), making it simpler than before to upgrade an XWiki instance.
  • Get closer to cloud needs. Nowadays, could offerings happen more and more and operating a cloud means bringing improvements and fixes as fast as possible. Some software in the cloud are even updated/patched several times per day. We’re not there yet but we’re trying to get closer by reducing from 3 months to 1 month (we used to release the minor versions every 3 months).
  • This also means more marketing for the xwiki project since other sites relay the news whenever a final version is released emoticon_smile

Release quality

All releases are as stable as possible. It is very unlikely that something will "blow up" in a new release, as the Continuous Integration setup assures that at almost any point XWiki is stable. Even snapshot builds, although not as thoroughly tested and not as polished as official releases, are most of the times stable. The short timespan dedicated to each version also imposes that no major code changes can occur during the development phase, so although some parts are "in development" between releases, most of the code should behave identically to the previous release.

The bugfix releases rarely solve critical bugs in their equivalent minor release, they usually backport bugs solved during the future release. These bugs aren't blockers, just things that need to be ironed out, so instead of waiting for the x.y.5 release, better try the most recent minor release, since it is almost as stable, but with even more bugs fixed and some new features.

Releases and SCM


We use Git and follow these rules:

  • master is our latest work, i.e. what will be the next release (you can check the Roadmap for it)
  • We have a few stable branches (named using the pattern stable-<version>.x (e.g. stable-4.1.x) which are bugfix branches for past releases. When an important bug gets fixed on master it's usually backported on those branches so that they get it when they're released (we don't have any Roadmap for bugfix branches - We just do them either when a critical bug is found, when people ask for it or when we consider there are enough fixes on them).
  • All releases have tags too (e.g. xwiki-commons-4.1.3 in the XWiki Commons git repository)
  • Developers are allowed to create feature branches when they work on experimental stuff that is not yet ready to be committed on master. The plan is that they merge it later on on master when it's ready and remove the feature branch

LTS Switching

When the last version of a Cycle is released (i.e. N.4), we wait till the first version of the next Cycle is released (i.e. N+1.0) before discarding the previous LTS (i.e. N-1.4.x) and marking the N.4.x release as the new LTS.


  • We need to have feedback on a release before it can be considered super stable and thus we usually need a few bug fix releases before a version can be considered a good LTS. Since the first release of next Cycle will happen about 1 month from the final release of the previous cycle, this gives us 1 month to release bugfix releases.
  • This also allows us to always support 3 branches:
    • LTS branch
    • Stable branch
    • master (latest SNAPSHOT)
Created by Vincent Massol on 2011/01/31 10:35

Get Connected