Loading...
 
(Cached)
Refresh Print
Tiki has a time-based, "Release early, Release often" approach with Long Term Support (LTS) versions, to balance the needs of stability and innovation.

Summary
  • There is a new major version (e.g. 12.x -> 13.x) every 6 months.
  • Minor versions (12.1 -> 12.2) are released as needed, typically every 1-2 months
  • You can upgrade from any supported version to any subsequent supported version at any time. However, there is no downgrade path. Please make sure you make a backup first.
  • Regular support period is until the x.1 release of the next version. For example, Tiki 13.x is supported until Tiki 14.1 is released.
  • Every 3rd version is Long Term Support (LTS)
    • LTS support period is 3.5 years for Tiki 9.x and 5 years for Tiki 12.x, going from a regular support period (with bug fixes and minor, self-contained enhancements) to a "security fix only" period.
    • 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 combine with an LTS environment (such as Ubuntu LTS).
    • You should not expect that LTS will be updated to work with newer PHP versions that were released after. However, in practice, this is never really a problem which occurs.
    • LTS is typically used for Enterprise deployments or other users that do not want frequent major upgrades (for example, if your environment requires software audits)
  • Since Tiki is 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 in other web applications)



Goals

  • Have a predictable system
    • At download time, users should know until 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 possibilities (jQuery, HTML5, SVG, etc.)
    • 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, 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 plan to upstream later, but the later never happens, or in the mean time, someone else implemented the feature in a different way, and it becomes very difficult to converge.

Here is a recap of innovations in last 5 years:

Not only Tiki has been for many years the Free and Open Source software Web Application with the most built-in features, Tiki is also the Free and Open Source Software Web Application with the fastest release cycle of the last 5 years.

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 or October)
  • Minor versions as needed, usually every 6-8 weeks
  • Every 3rd major version is a Long Term Support (LTS) version
  • Support period
    • LTS versions are supported for 3.5 years (Tiki9) or 5 years (Tiki12)
    • Non-LTS versions are supported until the next major release (6-8 months)

Version Lifecycle Diagram

  • Development phase in trunk (6 months)
  • Branch is started (This is when we diverge from trunk to stabilize a version, the month before the release of the x.0)
  • 0: Release of x.0 (every 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), but commits are monitored by the Quality Team (12 months)
  • S: Security fixes only, reviewed by the Quality Team or Security Team (Tiki9: 18 months; Tiki12: 36 months)
  • 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
        |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
6.x     RRRRQQQQQQQQQQQQQQQQQQSSSSSSSSSSSSSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |     |
7.x     DDB0RRRRRRE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
8.x     | DDDDDDB0RRRRRRE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
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...


From the creation of the branch, and until becomes too much work, there is a Semi-automatic merging period from the branch to trunk. This typically lasts 2-3 months.

If a x.0 is released late, the support of the previous version is extended. Ex.: 9.0 will be released in June instead of April, thus 8.x will be supported 2 months longer than usual. The important thing is that there are not any support gaps.

Strategies

So site admins have many choices.

Main concern Reason Strategy
I'll be developing new features Tiki has most of what I need, but I also want to add X Develop in trunk.
Your features will be in the stable/official Tiki version within 6 months, and it will become community supported. Please see how to get commit access
I want the new features Because they are cool! Upgrade to the new stable version every 6 months.
Depending on your eagerness vs tolerance to bugs (capacity to fix them), you may want to skip .0 versions
I want to upgrade less often A heavily customized theme Use LTS, and skip a version: ex.: Tiki 9.x LTS to Tiki 15.x LTS.
An upgrade every 36 months. Some can have concerns about upgrade difficulty but this isn't the case because if you skip ahead several versions, you are going through the same path as everyone else did in the previous years, but in an accelerated fashion. You can upgrade from Tiki 1.9.0 (released on 2005-04-27) to any later version of Tiki because all the upgrade scripts are part of the code base. This policy will be maintained to keep upgrades as easy as possible.
Once I deploy, I want minimal changes Need to audit the code Move from one LTS to another (ex.: 9.x to 12.x) but start using when it is in security-fix-only phase.
An upgrade every 18 months, but after that it's only security fixes.
I want the least possible number of bugs I have a huge user-base and they are grumpy. Go from one LTS to the next.
Since the version you are using will be over 2 years old, bugs will be rare. You should at least test (and if possible deploy) before the security-only period so you may detect any bugs, report them (and ideally, you arrange to get them fixed)
I want the best possible security My site is a potential target Go from one LTS to the next, in the security-only phase.
Since the version you are using will be over 2 years old, most vulnerabilities have been found and resolved. And for anything remaining, the security team will address.


If you are using Tiki LTS, you should consider deploying on a LTS server, such as Ubuntu LTS or CentOS (which is LTS in nature)

Upgrade paths examples

Use case Upgrade path
Eager for new features 9.0 -> 9.1 -> 9.2 -> 9.3 -> 10.0 -> 10.1 -> 10.2 -> 10.3 -> 11.0 -> 11.1 -> 11.2 -> 11.3 -> 12.0 -> 12.1 -> 12.2 -> 12.3 -> 13.0 -> 13.1 -> 13.2 -> 14.0 -> 14.1 -> 14.2 -> 15.0 -> 15.1 -> 15.2
Normal (skip .0 releases) 9.1 -> 9.2 -> 9.3 -> 10.1 -> 10.2 -> 10.3 -> 11.1 -> 11.2 -> 11.3 -> 12.1 -> 12.2 -> 12.3 -> 13.1 -> 13.2 -> 14.1 -> 14.2 -> 15.1 -> 15.2
LTS 9.3 -> 9.4 -> 9.5 -> 12.3 -> 12.4 -> 15.4 -> 15.5
Skip LTS 9.3 -> 9.4 -> 9.5 -> 15.3 -> 15.4 -> 15.5
Skip 2 LTS 12.3 -> 12.4 -> 12.5 -> 21.3 -> 21.4 -> 21.5


PHP versions

Tiki is constantly evolving and taking advantage of new possibilities of PHP. However, 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.

Tiki version PHP requirement
3LTS, 4 5.0
5, 6LTS 5.1
7, 8, 9LTS 5.2
10, 11, 12LTS 5.3
13, 14, 15LTS 5.5 with a focus on the new Zend OPcache


Desktop browsers

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, 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.


Tiki version Internet Explorer version
6LTS IE6
7, 8, 9LTS IE7
10, 11, 12LTS IE8, which is the highest you can upgrade to if you have Win XPWhile Windows XP Service Pack 2 users can install the latest versions of Chrome, Firefox and Opera, they are limited to IE8. "On April 8, 2014, all support for Windows XP, including security updates and hotfixes, will be terminated." Source: http://en.wikipedia.org/wiki/Windows_XP#Support_lifecycle
13, 14, 15LTS IE9: see the discussion and stats. Note: Since IE11 has now been released, it is possible that support will be for IE10 and IE11 only, depending on how it goes with the Bootstrap integration.


Mobile browsers

Tiki uses jQuery Mobile, which has a progressive enhancement approach. Starting in Tiki13, Bootstrap will be used, which is a mobile-first framework.

The Future

As of December 2013, the release cycle is not expected to change for the foreseeable future. However, if it does change, it will remain the same general principle. And 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:



Join Tiki

Tiki Events

September 2014
Su Mo Tu We Th Fr Sa
31 01 02 03 04 05 06
07 08 09 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 01 02 03 04


Upcoming events:
Oct. 07, 2014
Happy Birthday Tiki

Show php error messages