From Koha Test Wiki MediaWiki Postgres

Contents 1 Koha versioning 1.1 Current Release Model 1.1.1 Version Numbering 1.1.1.1 16.05 -> Present 1.1.2 Development & Maintenance 1.1.3 Codenames 1.1.4 Recommendations 1.2 Prior Release Models 1.2.1 Version Numbering 1.2.1.1 1.0 -> 3.2 1.2.1.2 3.2 -> 3.22

Koha versioning

Koha has gone through a number of different versioning schemes over its 20 year existence

• Next proposals discussion

Current Release Model

Version Numbering

During the development cycle of Koha 3.24 the community decided to switch from a feature based version numbering scheme to a time-based one, with the first release following this scheme being 16.05.

XX.YY.ZZ.AAA

• XX - The release year.
• YY - The release month. (05 for May, 11 for November)
• ZZ - The maintenance increment. Denotes a 'bugfix' release. (The introduction of patches to fix bugs in existing features only, no enhancements and no new features)
• AAA - The database increment. This increment is used to track the database schema.

16.05 -> Present

• Pro: You will know easily how old is the version you are using
• Con: There isn't an obvious change in the version number to denote big feature changes

Development & Maintenance

A feature stable release is made once every six months, during May (XX.05) and November (XX.11), and a new release team is elected for the next six-month cycle at this time.

The feature stable release is then maintained for an average of 18 months (dependant upon volunteers for the maintainer role) and a new bugfix release, which includes many fixes for bugs backported from the upstream development version, is made each month during this period.

The development version of Koha should not be run in production and can be clearly distinguished by it's version number which will either be XX.06 or XX.12.

Codenames

With the above 18 month maintenance period, it results in usually supporting 3 feature stable releases concurrently and these follow the standard Debian repository naming scheme of stable, oldstable and oldoldstable.

As an example, in November 2018 the most current feature stable version of Koha is 18.11 and the community will be maintaining:

• Koha 18.11 (stable)
• Koha 18.05 (oldstable)
• Koha 17.11 (oldoldstable)

Recommendations

For production environments, the recommended method of installation is to use the debian packages, paying close attention to the follow a suite section.

• If you want to want to run the most bug-free release of Koha at any given time you should track the oldoldstable branch.
• If you want the most feature rich version of Koha and don't mind dealing with a few bugs every few months then the stable branch is for you.
• The happy middle ground of oldstable will get new features 6 months later than stable, but should be considerably more tried and tested and as such more bug free.

Prior Release Models

Version Numbering

Koha's original version number scheme was based solely on features.

X.YY.ZZ.AAA

• X - The major increment. This was meant to denote a large change in Koha. (The introduction of zebra for bibliographic indexing for example)
• YY - The minor increment. This was meant to denote a new feature bundle release. (The introduction of new feature and enhancements to existing features that didn't warrant a major increment change)
• ZZ - The maintenance increment. This was meant to denote new bugfix releases. (The introduction of patches to fix bugs in existing features only, no enhancements and not new features)
• AAA - The database increment. This increment is used to track the database schema.

1.0 -> 3.2

Koha's original releases were based upon 'targeted features'. The community would set out what they aimed to achieve at the beginning of a cycle and the release would only become official once all those features were implemented.

• Pro: You know what you will have
• Con: Delayed releases (more than 1 year for 3.2)

3.2 -> 3.22

After the unusually long wait for the 3.2 release of Koha, the community decided to adopt a time-based approach to releases. A minor release of Koha would be done every 6 months, independently from what new features it may contain.

• Pro: Predictable release dates
• Con: If a feature you were expecting hadn't made the cut by a certain deadline, you would have to wait a further 6 months for it to be included in an official release.