Fullscreen
[Show/Hide Right Column]

How long does a version live? Type of page »  Developers documentation
Print

Version lifecycle

Goals

  • Have a predictable system, where the community converges efforts on a common release cycle strategy.
  • Cater both to:
    • Users that want "Release early, Release often".
      • For people in a business setting, it's essential to be able to commit to a date with their customer. 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 pressure will make them fork their version and the community will often lose those contributions.
    • Users that want a supported version (with security fixes), with minimal upgrade effort / change.
  • Manage as few branches as possible (more than 3 is unrealistic)

Background information

Since Tiki2, we follow time boxing approach like Gnome and Ubuntu, with a new major release every 6 months (October and April). Whatever isn't ready in time is deferred to the following release. There are several branches (Stable, Proposals, Dev, Experimental, Legacy)

If a change requires more time to implement, we break it into multiple parts and work on each chunk in each cycle. Workspaces is an example of a major change taking place over 2 versions.

Since all features are bundled in Tiki (vs having hundreds/thousands of extensions/plugins), we have inherent synchronized releases of all features.

When do we stop making bug and/or security fixes on previous versions? The goal is to make upgrades easy, but in many cases, site admins (ex.: in the Enterprise) do not want to upgrade... but they still want to get security fixes. If we tried to support for 2 years, we would have 4 versions to support plus the upcoming one! This would mean that a bug fix would have to done on up to 5 versions. And since code changes, the bug fix can't just be blindly copied. It must be tested. Reality check: As a community, we have to be very realistic about how much energy we'll have for this. Developers tend to be interested in working on new versions.

Thus, it was decided to mark certain versions as Long Term Support, and converge our energies on these. Tiki 3.x was the first official long term support version. The current LTS is 6.x

Background reading: Meta-cycles: 2-3 year major cycles for free software? and the follow-up: 2 year cadence for major releases: some progress

Release & branching strategy

7.x 2011-04

Tiki7 follows the same general process as Tiki 6 except that

  • everything is 6 months later
  • branches/6.x is not closed, as it will become LTS

Release 7.1 (May 2011)
  • Tiki 6.x (which is 7-months old by now) becomes LTS
  • Release one final 3.x LTS
    • Tiki 3.x is closed. (around May 2011, thus 2 years after 3.0 release)
    • LTS users will upgrade (for example) from 3.7 to 6.3
      • For data, it will be easy thanks to the Database Schema Upgrade and already widely tested because everyone in the community has gone though that process over last 2 years.
        • This being said, testing the direct 3.x to 6.x/7.x upgrade is important because there could be some issues only visible when you do such a jump.
      • For customizations however, they most likely need to be redone either in similar hacking way or by using the newly available possibilities.
  • Semi-automatic merging period ends and Quality Team goes in "strict mode". If you want to fix something for an eventual 6.4 LTS
    1. commit to trunk (for 8.0)
    2. commit to proposals/7.x (for 7.2, etc.)
    3. commit to proposals/6.x LTS (for 6.5, etc.)


8.x 2011-10

Tiki8 regular dev period (April -> September 2011)
  • Everyone commits to trunk (while avoiding major changes in trunk that either won't be ready for the next release or are not intended for the next release). Use Experimental branches instead.
  • If you have changes to trunk (typically changes to a large number of files) that will increase the difficulty of the 7.x -> 8.x Semi-automatic merging period, please do them after the merges are stopped (usually about when 7.1 is released)

As 8.0 is approaching (September 2011)
  1. Pre
    • Solve outstanding issues
    • Do a run of the "Preparatory work" of How to release (better to do before branching)
  2. branches/8.x is started
  3. Some *.tiki.org sites are migrated to branches/8.x
  4. Institute semi-automatic merging period from branches/8.x to trunk] (future 9.x)
    • Everyone commits to branches/8.x (unless it's only for 9.x)
      • Merge from branches/8.x to trunk (future 9.0) is handled by script so you can commit to branches/8.x until 8.1 is released. All devs should try to update the sites they manage during this period, because the process is simpler than after 8.1


8.0 is released (October 2011)
  1. All *.tiki.org sites are running branches/8.x
  2. Quality Team starts to check all commits and rollback any issues. "soft mode" -> dogfooding Code Review
  3. Release one last 7.x stable (ex.: 7.4) with everything that is in proposals/7.x (which is closed after)
  4. Merge from branches/8.x to trunk (future 9.0) is handled by script so you can commit (with extreme caution!) to branches/8.x until 8.1 is released. All devs should try to update the sites they manage during this period, because the process is simpler than after 8.1


Release 8.1 (November 2011)
  1. branches/7.x is closed, as all focus goes on branches/8.x
  2. proposals/8.x is created and Semi-automatic merging period ceases.
  3. Quality Team goes in "strict mode".


If you want to fix something for an eventual 8.2:

  1. commit to trunk (for 9.0)
  2. commit to proposals/8.x (for 8.2, etc.)


If you want to fix something for an eventual 6.5: (a lot of work!)

  1. commit to trunk (for 9.0)
  2. commit to proposals/8.x (for 8.4, etc.)
  3. commit to proposals/6.x (for 6.5, etc.)


9.x 2012-04

Tiki9 follows the same general process as Tiki 8 except that

  • everything is 6 months later


Since Tiki 9.x will be the next LTS, if you have a major change to make, avoid making it for Tiki9. After 9.1 is the best time to introduce major architectural changes for Tiki10, as it won't interfere with merge up script, and there is still plenty of time to deploy everywhere.

10.x 2012-10

Tiki10 follows the same general process as Tiki 9 except that

  • everything is 6 months later
  • branches/9.x is not closed, as it will become LTS

Release 10.1 (November 2012)
  • Tiki 9.x (which is 7-months old by now) becomes LTS
  • Release one final 6.x LTS
    • Tiki 6.x is closed. (around November 2012, thus about 18 months years after 6.0 release)
    • LTS users will upgrade (for example) from 6.7 to 9.3
      • For data, it will be easy thanks to the Database Schema Upgrade and already widely tested because everyone in the community has gone though that process over last 18 months.
      • For customizations however, they most likely need to be redone either in similar hacking way or by using the newly available possibilities.
  • Quality Team goes in "strict mode". If you want to fix something for an eventual 9.4 LTS
    1. commit to trunk (for 11.0)
    2. commit to proposals/10.x (for 10.2, etc.)
    3. commit to proposals/9.x LTS (for 9.4, etc.)



11.x and beyond 2013-04

Since Tiki2, the release process has improved dramatically and the Continuous Testing Server is expected to further improve the situation.

As of March 2012, the release schedule is not expected to change for the foreseeable future. However, if it does change, it will be for a faster release cycle (ex.: every 4 months in February, June and October), 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).

Upgrade paths

Eager for new features 3.1 -> 3.2 -> 3.3 -> 4.0 -> 4.1 -> 4.2 -> 4.3 -> 5.0 -> 5.1 -> 5.2 -> 5.3 -> 6.1 -> 6.2 -> 6.3 -> 7.0 -> 7.1 -> 7.2 -> 8.0 -> 8.1 -> 8.2 -> 9.0 -> 9.1
Normal (skip .0 releases) 3.1 -> 3.2 -> 3.3 -> 4.1 -> 4.2 -> 4.3 -> 5.1 -> 5.2 -> 5.3 -> 6.1 -> 6.2 -> 6.3 -> 7.1 -> 7.2 -> 8.1 -> 8.2 -> 9.1 -> 9.2
LTS 3.3 -> 3.4 -> 3.5 -> 3.6 -> 3.7 -> 6.3 -> 6.4 -> 9.3 -> 9.4


Benefits

  • Only 3 branches are maintained by developers at any given time, and only one that accepts significant changes.
    • Permits to focus eyeballs: Anything that is not risk-free (ex.: new features, or re-factor) is always done in trunk, thus all eyeballs are focused in the same place. So, if a change has a side-effect, it can be caught early. We don't fall in the dependency-hell trap.
  • Provides homes both for:
    • Fast pace of development
    • Stability and limited upgrades
  • We can still make quick .x releases on stable and LTS branches for security fixes, bug fixes, and changes to APIs. Ex.: A reported change in the Facebook API

Drawbacks

  • Previous branch (if not LTS) is dropped as soon as a .0 is released. Ex.: Once 5.x is released, 4.x is no longer maintained.
    • Thus, if you use 3.x LTS, and you decide to upgrade to 4.x, you may have regressions. If you want to upgrade from LTS, it should be to latest stable at the current time of the upgrade. This one will contain all the fixes that LTS has.
  • Except for LTS, versions are only supported for 6 months.
    • If you need Long Term Support on other versions, you can always get professional support from Consultants.
  • While it's OK to add completely new features, it is best to avoid major infrastructure developments (the ones that have a chance to introduce a lot of bugs/changes throughout the application) for LTS versions (like 6 and 9)
  • While in the semi-automatic merging period, sweeping changes (inc. cleanups) on trunk must be avoided (about 4-8 weeks per 6-month period)

Extended LTS idea

For many years now (and for the forseeable future!), Tiki has been the FOSS Web Application with the most built-in features. For many projects, upgrading to a new version is an annoyance because the existing version does everything needed and more. Because the 6-month release cycle was too frequent for some in our community, LTS versions were introduced. But even 18-24 months for LTS is also too frequent for some, so perhaps we could have an extended LTS period for security fixes.

Benefits

  • Better for inclusion in Debian and Ubuntu LTS repositories
  • Great for the enterprise
  • Great for major projects which want to use Tiki more as a Framework.
  • Great for web design shops which make highly customized designs. By the end of the support period, it will be time to make a new site design anyway.
  • Aligns us with Ubuntu, which has added extended LTS as well.

Drawbacks

  • More work
  • Risk of dispersing community energy on more versions

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)
  • Release of x.0
  • Stable with bug fixes and minor, self-contained enhancements (normally 6 months; 12 months for LTS versions)
  • Long term support, monitored by the Quality Team (12 months)
  • EXtended Support: security fixes only, by the Security Team (24 or 36 months depending if LTS is every 3 or 4 releases)
  • E End-of-Life (Eol)

LTS every 3 versions

Year -> |    2011   |    2012   |   2013    |    2014   |    2015   |    2016   |    2017   |    2018   |    2019   |
Month-> JFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASOND|
        |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     | 
6.x     SSSSLLLLLLLLLLLLLLLLLLE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
7.x     DDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
8.x     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
9.x     |     | DDDDDDBRSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXE |     |     |     |     |     |     |     |     |
10.x    |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |     |
11.x    |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |
12.x    |     |     |     |     | DDDDDDBRSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXE |     |     |     |     |     |
13.x    |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |
14.x    |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |
15.x    |     |     |     |     |     |     |     | DDDDDDBRSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXE |     |     |
16.x    |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |
17.x    |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |
18.x    |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXE
19.x    |     |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |
20.x    |     |     |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |
21.x    |     |     |     |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXE



LTS every 4 versions

This would put us in sync with Ubuntu LTS 

Year -> |    2011   |    2012   |   2013    |    2014   |    2015   |    2016   |    2017   |    2018   |    2019   |
Month-> JFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASOND|
        |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     | 
6.x     SSSSLLLLLLLLLLLLLLLLLLE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
7.x     DDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
8.x     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
9.x     |     | DDDDDDBRSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE |     |     |     |     |     |     |
10.x    |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |     |
11.x    |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |
12.x    |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |
13.x    |     |     |     |     |     | DDDDDDBRSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE |     |     |
14.x    |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |
15.x    |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |
16.x    |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |
17.x    |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE
18.x    |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |
19.x    |     |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |
20.x    |     |     |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |
21.x    |     |     |     |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE

LTS every 4 versions with longer stable period before Quality Team starts

This would put us in sync with Ubuntu LTS 

Year -> |    2011   |    2012   |   2013    |    2014   |    2015   |    2016   |    2017   |    2018   |    2019   |
Month-> JFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASONDJFMAMJJASOND|
        |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     | 
6.x     SSSSLLLLLLLLLLLLLLLLLLXXXXXXE |     |     |     |     |     |     |     |     |     |     |     |     |     |
7.x     DDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
8.x     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |     |     |     |
9.x     |     | DDDDDDBRSSSSSSSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE |     |     |     |     |     |     |
10.x    |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |     |
11.x    |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |     |
12.x    |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |     |     |
13.x    |     |     |     |     |     | DDDDDDBRSSSSSSSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE |     |     |
14.x    |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |     |
15.x    |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |     |
16.x    |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |     |     |
17.x    |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE
18.x    |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |     |
19.x    |     |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |     |
20.x    |     |     |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSE |     |     |     |
21.x    |     |     |     |     |     |     |     |     |     |     |     |     |     | DDDDDDBRSSSSSSSSSSSSLLLLLLLLLLLLXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXE

Strategies

So site admins would have more choices.

Main concern Reason Strategy Notes
I'll be developing new features Tiki has most of what I need, but I also want to add X Develop in trunk, and your features will be in the stable/official Tiki version within 6 months, and it will become community supported 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 Skip a version: ex.: Tiki 9.x LTS to Tiki 15.x LTS An upgrade every 36 or 48 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.8.0 (released on 2004-02-08) to any later version of Tiki because all the upgrade scripts are part of the code base. There is no plan to change this, as it would save a tiny bit of disk space and make upgrades more difficult.
Once I deploy, I want minimal changes Need to audit the code Move from 1 extended LTS to another (ex.: 9.x to 12.x) 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 userbase and they are grumpy. Go from one extended 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 extended 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 extended to the next 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.

Things to discuss / be careful about

  • What is policy of included code?
  • What if a future version of a Tiki requirement (PHP/MYSQL/Apache) breaks something during the LTS or extended LTS period?
    • PHP 5.2.x is no longer supported but still used by a lot of hosts. Tiki works well on PHP 5.2 and 5.3
      • We should test with PHP53Compat_CodeSniffer
      • Tiki9LTS is supported for the PHP/MYSQL/Apache version which were available when it was being developed. ex.: Tiki9 LTS is widely tested in 5.2 and 5.3 It is expected to work in future versions, but if PHP (ex.: 5.5) makes some non-backward compatible changes, the LTS version will not be adapted to work with it.
    • Tiki 9 installs fine on MySQL 4.1.22 (although some of the upgrade scripts require MySQL 5) so it's safe to assume that future versions of MySQL will be fine
    • We should perhaps suggest to pair this with LTS servers and browsers?
  • What if a future version of a major browser breaks something during the LTS or extended LTS period?
  • What if a bundled external library has a security issue and it's no longer supported?
    • We'll inform users about the risks and that they should discontinue the use of the features that require this library.
  • Update notifier
  • How do we deal with documentation?
    • Maybe the Preferences report script could indicate which versions have the given feature?
    • Perhaps we should try to have more docs in the app (easier said than done)
    • Use PluginVersions
  • We could reduce LTS from 18 to 12 months, and increase extended from 18 months to 24 months
  • Instead of extended LTS, should we just make LTS versions less often? (ex.: every 4th or 5th Tiki release)
  • Make sure that demo.tiki.org has all the LTS and extended LTS versions
  • Experimental features: preferences tagged as experimental in tiki-admin.php should not be covered by XLTS

Definition of (X)LTS

  • The extended LTS period is intended for security fixes, but could include a few bug fixes as well.
    • We will review security vulnerabilities reported to the Security Team
    • Publish a fix or a way to deactivate the feature.
      • If the included code doesn't have a patch for that version
  • What if a security vulnerability requires major code changes, that are not suitable for LTS or extended LTS?
    • We'll disable the feature via System Configuration so you can can choose to use it knowing the risks, decide not to use it, or upgrade.


Related links

Alias

Page last modified on Monday 19 March, 2012 20:56:12 UTC

SourceHistoryComments

Search Wishes (subject only) [toggle]

Categorize Version lifecycle

Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.