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.
    • Typically, Enterprise users.
• 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 has been picked as the first long term support version. The next LTS will be 6.x and will replace 3.x LTS, when 7.1 is released.

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

6.x 2010-10

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.

1. Pre
   • Solve outstanding issues
     • Merge all experimental branches
     • Remove any code that should be -> Endangered features
2. branches/6.x is started
3. Some *.tiki.org sites are migrated to branches/6.x
4. Institute merging from branches/6.x to trunk (future 7.x)
   • Everyone commits to branches/6.x (unless it's only for 7.x) -> you don't have to worry about merging up to trunk (future 7.x)

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

1. proposals/6.x is created and merges via script cease.
2. Quality Team goes in "strict mode".

Since Tiki 6.x is LTS, after 6.1 is the best time to introduce major architectural changes for Tiki7, as it won't interfere with merge up script, and there is still plenty of time to deploy everywhere.

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

1. commit to trunk (for 7.0)
2. commit to proposals/6.x (for 6.2, etc.)
3. commit to proposals/3.x (for 3.8, etc.)

If you want to fix something for an eventual 6.2:

1. commit to trunk (for 7.0)
2. commit to proposals/6.x (for 6.2, etc.)

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 abandoned, as it will become LTS

• Tiki 6.x (which is 7-months old by now) becomes LTS
• Release one final 3.x LTS
  • Tiki 3.x is abandoned. (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.
    • 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 6.4 LTS

1. commit to trunk (for 8.0)
2. commit to proposals/7.x (for 7.1, etc.)
3. commit to proposals/6.x LTS (for 6.4, etc.)

8.x 2011-10 and beyond.

The general recipe will likely repeat itself.

Since Tiki2, the release process has improved dramatically. The Continuous Testing Server is expected to further improve the situation. Thus, it is possible that we'll shorten the release cycles to 4 months (ex.: February, June and October), while maintaining LTS versions every 18 to 24 months.

Tiki 6.x LTS will be released around May 2011. Thus, the next LTS version will likely be released around November 2012.

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
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
LTS	3.3 -> 3.4 -> 3.5 -> 3.6 -> 3.7 -> 6.3 -> 6.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

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.

Related links

• http://en.wikipedia.org/wiki/Software_configuration_management
• http://www.mediawiki.org/wiki/Version_lifecycle
• http://drupal.org/handbook/version-info
• http://fedoraproject.org/wiki/LifeCycle
• http://wiki.ubuntu.com/TimeBasedReleases

• Where to commit
• How to release
• RoadMap
• Freeze and Slush
• Model

Alias

• LTS
• Long Term Support
• Meta-cycles
• Release schedule
• cycle
• lifecycle

---