Version lifecycle

Table of contents

• Background information
• Goals
• Release & branching strategy
  • 4.x 2009-10
  • 5.x 2010-04
  • 6.x 2010-10
  • 7.x 2011-04
  • 8.x 2011-10
• Upgrade paths
• Benefits of this proposal
• Drawbacks
• Todo
• Related links
• Alias

Background information

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

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! 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 on working on new versions.

Background reading: Meta-cycles: 2-3 year major cycles for free software?

Goals

• Release early, Release often, a minimum of 2 major releases per year.
• Manage as few branches as possible (more than 3 is unrealistic)
• Have a predictable system, where the community converges efforts on a Long Term Support strategy.

Strategy:

• To mark certain versions as Long Term Support, and converge our energies on these. The first one is 3.x LTS

If you need Long Term Support on other versions, you can always get professional support from Consultants

Release & branching strategy

4.x 2009-10

This is example plan for 4.0 It provides a glimpse in the future.

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

1. Pre
   • Merge all experimental branches (Kaltura, etc.)
   • Remove any code that should be
   • Solve outstanding issues (ex.: Workspaces)
   • Release a stable version (3.2)
2. Branch 4.0
3. Institute merging from branch4 to trunk
   • Everyone commits to branch4 -> you don't have to worry about merging up to trunk

1- Quality team starts
2- proposed branch is renamed. Ex.: proposals/3.x
3- new proposed branch for 4.1, 4.2, etc. Ex.: proposals/4.x

An amnesty is granted for 7-14 days after 4.0, where you can still commit to branches/4.x

If you want to fix something for an eventual 3.5: (a lot of work!)
1- commit to trunk
2- commit to proposals/4.x branch (for 4.2, etc.)
3- commit to proposals/3.x branch (for 3.5, etc.)


If you want to fix something in an incremental release of 4, then
1- commit to trunk
2- backport to proposals/4.x branch

5.x 2010-04

Before 5.0

• Release one last 4.x stable (ex.: 4.2) (unless major problem)
• branches/5.x is started
• branches/4.x is abandoned, as all focus goes on branches/5.x

5.0

• Quality Team starts to check all commits and rolls back any issues. "soft mode"
• Merge to trunk (future 6.0) is handled by script
• All devs should try to update the sites they manage during this period, because the process is simpler.

Release 5.1

• Quality Team goes in "normal mode". If you want to fix something for an eventual 3.4: (a lot of work!)

1. commit to trunk (for 6.0)
2. commit to proposals/5.x (for 5.1, etc.)
3. commit to proposals/3.x (for 3.4, etc.)

• This is the best time to introduce major architectural changes for Tiki6, as it won't interfere with merge up script, and there is still plenty of time to deploy everywhere. But keep in mind that Tiki6 may become LTS.

6.x 2010-10

Before

• Release one last 5.x stable (ex.: 5.3)
• branches/6.x is started
• branches/5.x is abandoned, as all focus goes on branches/6.x

6.0

• Quality Team starts to check all commits and rollback any issues. "soft mode"
• Merge to trunk (future 7.0) is handled by script

Release 6.1

• Quality Team goes in "normal mode". If you want to fix something for an eventual 3.5: (a lot of work!)

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

• This 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.

7.x 2011-04

Before

• Release one last 6.x stable (ex.: 6.3)
• branches/7.x is started
• branches/6.x is not abandoned, as it will become LTS

7.0

• Quality Team starts to check all commits and rollback any issues. "soft mode"
• Merge to trunk (future 8.0) is handled by script

Release 7.1

• Tiki 6.x (which is 6-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.5 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 "normal 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.)

• This is the best time to introduce major architectural changes for Tiki8, as it won't interfere with merge up script, and there is still plenty of time to deploy everywhere.

8.x 2011-10

Before

• Release one last 7.x stable (ex.: 7.3)
• branches/8.x is started
• branches/7.x is abandoned, as all focus goes on branches/8.x

8.0

• Quality Team starts to check all commits and rollback any issues. "soft mode"
• Merge to trunk (future 9.0) is handled by script

Release 8.1

• Quality Team goes in "normal mode". If you want to fix something for an eventual 6.5 LTS: (a lot of work!)

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

• This is the best time to introduce major architectural changes for Tiki9, as it won't interfere with merge up script, and there is still plenty of time to deploy everywhere.

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 of this proposal

• Only 3 branches are maintained by developers at any given time
  • Permits to focus eyeballs
• 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.

Todo

• Improve/approve this plan

Related links

• http://en.wikipedia.org/wiki/Software_configuration_management
• http://www.mediawiki.org/wiki/Version_lifecycle
• http://drupal.org/handbook/version-info
• Where to commit
• How to release
• RoadMap
• Freeze and Slush
• Model

Alias

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

---