Version Names

• LTS Release (a.k.a Cycle LTS): This is the most stable version and is what we recommend to use in production.
• Intermediate LTS Release: The difference between the current Cycle Intermediate LTS and the previous Cycle LTS is that the Intermediate LTS allows users in production to use the newest features of XWiki. It’s super stable but the newest features will have less time to mature than what you’d find if you waited for the current Cycle LTS, at the end of the year.
  • If some of the new features present in the Intermediate LTS are important for you, we recommend that you upgrade to it.
  • If you’re starting with a new installation of XWiki (i.e. you’re not upgrading), we also recommend that you start with it, as it contains the latest and best features.
  • If upgrading XWiki is hard for you (e.g. lots of customizations) and the new features are not of a particular interest, then we recommend that you stay on your current LTS and wait till the next LTS (at end of year).
• Stable Release: This is the version recommended if you wish to try out the latest features from the current Cycle. 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

Format: Major.Minor.Bugfix[-rc-number|-SNAPSHOT]. The Bugfix part is always written, even when it is 0.

XWiki <16.0.0 The Bugfix part used to be indicated only when not 0.

Release Cycles and Release Strategy

The Cycle

A Release Cycle is all the releases of a major version N: 11 minor releases, N.0 to N.10, one per month from January to November.

The LTS stabilization releases contain mostly bug fixes.

Supported LTS Versions

• We support 1 LTS per Cycle, and at most 2 LTS in parallel.
• The Intermediate LTS doesn't replace the previous Cycle LTS, since they're on different Cycles. So around the middle of the year the Download page lists both: the previous Cycle LTS and the new Intermediate LTS.
• Once the Cycle LTS is released, it replaces the Intermediate LTS of the same Cycle.

Bugfix Releases

• On an LTS branch:
  • N.4.1 / N.4.2 and N.10.1 / N.10.2: one every 2 weeks, see above.
  • After that: release regularly, without too much time between 2 releases. The committers review the fixed issues and decide when to release.
  • We can release as soon as blocker issues are fixed, even if other important issues (including other blocker issues) are still open. The goal is an LTS as stable as possible, as quickly as possible.
• On other branches: the committers decide, depending for example on how close the next minor release is.

What to do when a N.4.2 or N.10.2 version is released

Announce it:

• Post in the "Help / Discuss" category of the forum that the Intermediate LTS or Cycle LTS is ready, and encourage users to start using it.
  • Cycle LTS only: explain the major features implemented during the Cycle (make special Release Notes for the Cycle).
• Make sure that N.4.2 and N.10.2 are announced as LTS in the blog post for their release.
• Update the versions page to list the new LTS.

Update the distribution channels:

• Debian repositories, by editing the scan_packages.sh script and pulling it on maven.xwiki.org:
  • Intermediate LTS: point the lts-latest repository to N.4.
  • Cycle LTS: point the lts-latest and lts repositories to N.10.
• The official Docker XWiki image:
  • Intermediate LTS: move the lts-latest tags from the previous LTS version to N.4.2.
  • Cycle LTS:
    • Point both the lts-latest and lts tags to N.10.2, removing lts-latest from N.4.2+ and lts from the previous LTS version.
    • Keep the stable tags on the new LTS version, and keep the previous LTS version definitions, until we release N+1.0.

Cycle LTS only:

• Check if there are important issues to release in the previous LTS branch, and schedule a last release if need be.
• Create a JIRA task for adding an automatic upgrade test from the new LTS (in xwiki-platform-distribution-flavor-test-upgrade).
• Create a blog post highlighting the Cycle release notes, using Highlights for the 15.x cycle as template.

Why We Release This Way

Major releases:

• Mark progress to the outside world, which helps open source marketing.
• Are a milestone in the project's life, and make us developers proud of our achievements.
• Are a good time to step back and think about what the XWiki project is and where it wants to go.

Monthly releases:

• Stabilize our CI builds faster: shorter releases mean fewer changes, so less stabilization.
• Get changes, and especially bug fixes, to our users faster. Users don't have to upgrade as fast: they can skip versions.
• Get feedback from users faster: users only test final versions, not RCs, so more final releases surface problems sooner. Our upgrade tools (the Distribution Wizard) make upgrading simpler than before.
• Get closer to cloud needs, where improvements and fixes are delivered as fast as possible (we used to release minor versions every 3 months).
• More marketing for the project, since other sites relay the news of each final release.

Release quality

All releases are as stable as possible. Our Continuous Integration keeps XWiki stable at almost any point: even snapshot builds, although not as thoroughly tested or polished as official releases, are stable most of the time. The short time dedicated to each version also prevents major code changes during development, so most of the code behaves like in the previous release.

Bugfix releases rarely fix critical bugs of their minor release: they usually backport bugs fixed for the next release. These bugs aren't blockers, just things to iron out, so rather than waiting for the x.y.z release, try the latest minor release: it's almost as stable, with even more bugs fixed and some new features.

Releases and SCM

We use Git with these rules:

• master holds our latest work, i.e. the next release (see the Roadmap).
• Stable branches, named stable-<version>.x (e.g. stable-17.10.x), are bugfix branches for past releases. Important bug fixes made on master are usually backported to them. Bugfix branches have no Roadmap: we release them when a critical bug is found, when people ask for it, or when there are enough fixes.
• Every release is tagged (e.g. xwiki-commons-17.10.2 in the XWiki Commons repository).
• Developers can create feature branches for experimental work that isn't ready for master, then merge them into master when ready and delete them.