Summary

• There is a new major version (e.g. 13.x -> 14.x) every 6 months.
• Minor versions (14.1 -> 14.2) are released as needed, typically every 1-2 months
• You can upgrade from any supported version to any subsequently supported version at any time. However, there is no downgrade path. Please make sure you make a backup first.
• The support period for non-LTS versions is at least until the x.1 release of the next major version. For example, Tiki 13.x is supported at least until Tiki 14.1 is released.
• Every 3rd version is a Long Term Support (LTS) version.
  • LTS support period is 5 years (since Tiki 12.x LTS), and consists of a period of ongoing features support (bug fixes and minor, self-contained enhancements) followed by a "security fix only" period over this timeframe.
  • LTS is expected to have minimal changes, no regression bugs, and little or no changes to Tiki behavior and continued security fixes for an extended period of time. It's a good idea to install LTS versions on a similarly long-term supported server environment.
  • You should not expect LTS versions to be updated to solve an issue introduced by a newer PHP version that is released after. However, issues of this type have historically been very rare and a patch to resolve such an issue would be analyzed by the development team.
  • LTS is typically used for Enterprise deployments or by other users that do not want frequent major upgrades (for example, if your environment requires software audits before every software installation)
• Since Tiki has an all-in-one model, all features are released at the same time, and you don't need to wait for 3rd party extensions / plugins / modules to be updated (which is very common and often painful in other web applications)

Goals

• Have a predictable system
  • At download time, users should know when the version is supported.
  • Time-based releases permit community members to self-organize to make sure specific developments are ready in time for the release.
• A rapid release cycle
  • To take advantage of new technological innovations
  • Encourages contributions to the main code base as contributors see their enhancements rapidly become available as part of the next release, where they are tested, documented and improved.
• Caters to diverse needs, so the community converges efforts
  • Users that want to have early and frequent access to the latest and greatest, and experimental features.
  • Users that want a supported version (with security fixes), with minimal upgrade effort / change, typically, enterprise users.
• Easy to manage
  • Easy to explain and understand
  • Manage as few branches as possible

Why predictable and rapid are both important

Feature enhancements are often the fruit of sponsored feature requests, or for needs to deliver a specific project. Site managers or IT departments can do themselves or choose to hire Tiki Consultants. The vast majority of the time, the sponsor is happy or requires that enhancements become part of the official code base. However, the timeline has to be reasonable. By having a set date (which is not too far off), there is an incentive to commit to trunk (the development version which will eventually become the current stable version), and know when it will become stable. Otherwise, customer/project pressure will make them fork their version and the community will often lose those contributions. They might plan to upstream later, but the later never happens, or in the meantime, someone else implemented the feature in a different way, and it becomes very difficult to converge.

Here is a recap of innovations in past years:

• 2009-05: Tiki3 LTS
• 2009-11: Tiki4
• 2010-06: Tiki5
• 2010-11: Tiki6 LTS
• 2011-06: Tiki7
• 2011-11: Tiki8
• 2012-06: Tiki9 LTS
• 2012-12: Tiki10
• 2013-07: Tiki11
• 2013-11: Tiki12 LTS
• 2014-08: Tiki13
• 2015-05: Tiki14
• 2016-04: Tiki15 LTS
• 2016-11: Tiki16
• 2017-04 (planned): Tiki17

There is a huge part of our user base that does not want/need new features, but only bug fixes and security fixes. This is why Long Term Support (LTS) versions were introduced in 2009. The support period was extended in 2012 to 3.5 years (applicable to 6.x LTS and 9.x LTS), and extended once more in 2013, to 5 years (applicable to 12.x LTS). Even if they don't need the new features now, site admins are pleased to know that they will have easy access to them when they upgrade.

The cycle

• A new major version twice per year (every April and October)
• Minor versions as needed, usually every 6-8 weeks
• Every 3rd major version is a Long Term Support (LTS) version (Tiki 9.x, 12.x, 15.x, 19.x...)
• Support period
  • LTS versions are supported for 5 years (starting from Tiki12)
  • Non-LTS versions are supported until the x.1 release of the next major version (exceptions might be made to delay this to the x.2 version if the x.1 version is released very close to x.0).

Version Lifecycle

• Development phase in trunk (6 or 12 months)
• Branch is started (This is when we diverge from trunk to stabilize a version, about 6 weeks to 2 months before the release of the x.0)
• 0: Release of x.0 ( April or October)
• R: Regular support period with bug fixes and minor, self-contained enhancements (normally 6 months; 12 months for LTS versions)
• Q: All developers commit to the branch (as usual) (12 months)
• S: Security fixes only
• E: End-of-Life (EOL)

A visual chart of the support period

Year -> |    2011   |    2012   |   2013    |    2014   |    2015   |    2016   |    2017   |    2018   |    2019   |    2020   |
Month-> JFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJ
        |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
9.x     |     | DDDDDDB0RRRRRRRRRRRRQQQQQQQQQQQQSSSSSSSSSSSSSSSSSSE |     |     |     |     |     |     |     |     |     |     |
10.x    |     |     | DDDDDDB0RRRRRRE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
11.x    |     |     |     | DDDDDDB0RRRRRRE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
12.x    |     |     |     |     | DDDDDDB0RRRRRRRRRRRRQQQQQQQQQQQQSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSE |     |     |     |     |
13.x    |     |     |     |     |     | DDDDDDB0RRRRRRE |     |     |     |     |     |     |     |     |     |     |     |     |
14.x    |     |     |     |     |     |     | DDDDDDB0RRRRRRE |     |     |     |     |     |     |     |     |     |     |     |
15.x    |     |     |     |     |     |     |     | DDDDDDB0RRRRRRRRRRRRQQQQQQQQQQQQSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSE |     |
16.x    |     |     |     |     |     |     |     |     | DDDDDDB0RRRRRRE |     |     |     |     |     |     |     |     |     |
17.x    |     |     |     |     |     |     |     |     |     | DDDDDDB0RRRRRRE |     |     |     |     |     |     |     |     |
18.x    |     |     |     |     |     |     |     |     |     |     | DDDDDDB0RRRRRRRRRRRRQQQQQQQQQQQQSSSSSSSSSSSSSSSSSSSSSSSSSSS...
19.x    |     |     |     |     |     |     |     |     |     |     |     | DDDDDDB0RRRRRRE |     |     |     |     |     |     |
20.x    |     |     |     |     |     |     |     |     |     |     |     |     | DDDDDDB0RRRRRRE |     |     |     |     |     |
21.x    |     |     |     |     |     |     |     |     |     |     |     |     |     | DDDDDDB0RRRRRRRRRRRRQQQQQQQQQQQQSSSSSSSSS...
22.x    |     |     |     |     |     |     |     |     |     |     |     |     |     |     | DDDDDDB0RRRRRRE |     |     |     |
23.x    |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     | DDDDDDB0RRRRRRE |     |     |
24.x    |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |       DDDDDDB0RRRRRRRRRRRRQQQ...

Strategies

So site admins have many choices.

If you are using Tiki LTS, you should consider deploying on an LTS server, such as Ubuntu LTS or CentOS (which is LTS in nature). Or go for Tiki Suite and pick suite:ClearOS.

Upgrade paths examples

PHP versions

Thanks to the availability of LTS versions, Tiki can be aggressive in increasing the requirements and take advantage of new possibilities of PHP. Indeed, if your infrastructure is not evolving as quickly (which is typical in large enterprise settings), you can use the Long Term Support (LTS) versions of Tiki.

Browser support considerations

For desktop browsers, Tiki generally supports the current and previous stable versions. Firefox and Chrome have a rapid release cycle with auto-update and for Safari and Opera, users upgrade fairly quickly. So except for Internet Explorer and mobile browsers, we only have to worry about fairly recent browsers. For Internet Explorer, because upgrades are decided by the IT department or limited by the OS version, a significant portion of the user base doesn't use the latest version. Balancing the needs of innovation and stability, the Long Term Support (LTS) versions are perfect for Tiki to take advantage of all the new possibilities of newer browsers, while still offering a supported version for users that need to support older browsers.

The Future

As of the present time, the release cycle is not expected to change for the foreseeable future. However, if it does change, the same general principle will stay the same. And the total support period (as announced when you download) will not be reduced (but could be extended). Any eventual (and at this point, unlikely) change in policy will be amply discussed within the community before it happens. Potential changes are:

• Minor change in cycle speed: It could be for a slightly faster cycle (ex.: every 4 months in February, June, October, February, etc.), or a slightly slower release cycle (ex.: every 8 months in February, October, June, February, etc). It could even be a combination (ex: 4 months, 4 months, and then 8 months). This would be while maintaining LTS versions for approximately the same periods. So instead of an LTS every 3rd version (18 months), it would be every 4th (16 months) or 5th version (20 months).
• Alignment with larger ecosystem: Ubuntu's Mark Shuttleworth once wrote: "There’s one thing that could convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate with the other, large distributions on a coordinated major / minor release cycle.". The Tiki community would certainly participate in any similar initiative.

Related links

• http://php.net/supported-versions.php