mRFC 0008: Time-based Midgard Release Process

This document outlines a new release management process for Midgard CMS. This mRFC been submitted to the Midgard Community for discussion and approval under the Creative Commons Attribution-ShareAlike license.

The proposed release process is a Midgardization of the way the GNOME community makes a major release every six months.

Background

While the actual Midgard project is developing rapidly, the process of getting stable releases published has been a constant problem after the 1.2.x series. Basically the community makes too big expectations on how many new features or architectural changes would be required for a release.

This situation has effectively forced most of the Midgard user community to run their servers with some combination of CVS snapshots of the Midgard Framework, MidCOM and the administrative interfaces. This makes debugging potential problem situations very difficult as the version combinations can vary greatly.

In addition to stability problems, this situation has a negative impact on Midgard's public image. Even though lots of new developments happen, they are not visible to outside the active developer community because of lack of release announcements. This way Midgard is seen as getting left behind by other Open Source CMSs that have a more regular release cycle, even though number of new features or improvements might be greater in Midgard.

Currently the Midgard Framework and sub-projects like MidCOM have separate release cycles. This makes supporting new Framework features in the sub-projects very difficult. If their release schedules were synchronized addition application-level support for new features like MultiLang and Quota would be much easier.

Goals

• Removing the need to run production servers on CVS snapshots
• Making translation and binary packaging work easier
• Improving Midgard's public image by regular releases
• Reducing the release management workload by using a clearer process
• Combining the Midgard Framework and MidCOM release cycles
• Enabling a more aggressive deprecation strategy
• Enabling MidCOM and admin UI level support for new features

Release schedule

In the new model Midgard releases would be published in a time-based manner. In the beginning a quarterly release schedule would be recommended but this could be switched into six month schedule in case of slower pace of development.

The release cycle would be the following:

• Week 1: Test a CVS snapshot, ensure stability of all modules from developers
• Week 2: Beta. Feature and language string freeze, release beta source packages, translators should update their localizations
• Week 3: Release Candidate. Source packages and some binaries
• Week 4: Final release. Binaries and release announcement

There can be more than one Release Candidate if required for quality reasons. Each RC will push the final release date back by one week.

The schedule for next two releases should be always available in a calendar on the Midgard website and in a subscribe-able vCal format. The calendar should also generate notices to the midgard-dev mailing list. Making decisions on the release schedule and keeping the calendar updated are duties of the Release Manager.

Release numbering

The Midgard version number is split into three sections; generation, major and minor numbers.

First generation of Midgard is the current framework architecture. Second generation will be the MgdSchema-driven Ragnaroek architecture built on the GNOME libraries.

The major release number is an integer. Each time-based release changes this number.

Minor releases will be used only for critical security or other updates released between time-based major releases.

Example: Midgard 1.6.0 is the sixth major release in the first generation Midgard architecture.

Formatting of the version numbers must follow the PEAR conventions. Examples: 1.6.0beta, 1.6.0rc1, 1.6.0

In addition to the version number each release will also have a release name. This name should reflect to some happening or situation in the Midgard Community. For example, major release 1.5.0 was released during a Midgard developer meeting in Munich, and named "Biergarten".

Package creation

To support the new release process the creation of new Midgard release packages should be made as automated as possible.

Currently there exists a tool named makedist for creating the Midgard packages. However, this tool would need some improvements to really support the release process:

• Downloading latest Aegir and Spider from website and adding to data package
• Checking out latest MidCOM from CVS and adding to data package
• Tagging both Midgard and MidCOM CVS repositories with the release number
• Uploading the packages to a "snapshots" directory on Midgard website

To make downloading latest Aegir and Spider releases possible we either need to add support for an automatic "latest" download URL, or add a configuration file for makedist where the URLs to latest packages are located.

MidCOM CVS repository would need its own makedist script which would handle tagging of that repository and choosing which components and other packages would be added to the release package.

When these modifications have been done running the command "./makedist 1.7.0" in Midgard CVS should produce full release source tarballs complete with all needed data packages, tag the CVS and upload the packages to the website.

TODO: how to handle the uploads, simple scp to a static directory or some method of saving to net.nemein.downloads?

Translations

Each translation of Midgard should have a designated translator listed on a "translations" page on Midgard Project website.

The translators must be notified one week in advance to the beta cycle. During the beta cycle they should ensure that the language they're responsible of is up-to-date in MidCOM.

Binary packages

Binary packages for major platforms must have designated maintainers. The maintainers should ensure that Midgard packages can be built during the beta cycle.

Binary packages for the final release must be ready and available on the Midgard Project site before the release is announced.

Deprecation strategy

The time-based release process allows us to have a clear deprecation strategy. Features or modules may be deprecated during the course of four release cycles:

1. Announce that the module will be deprecated
2. Make the module optional
3. Remove the module from packages but keep it in CVS
4. Remove the module completely

This gives site and application maintainers a full year from first notice to remove dependencies to the deprecated module.

Examples of deprecation include removal of non-sitegrouped version of Midgard and the eventual removal of Apache 1.x support.

Optional features

The community should avoid optional features in Midgard Framework, as those make application writing more difficult. The process of adding new major features into Midgard mirrors the deprecation model, and can be accomplished in four elease cycles:

1. Add feature as optional and announce that it will be made default
   
2. Make the feature a default
3. Remove configuration option for disabling the feature
4. Remove IFDEFs for the feature from sources

Examples of new features that require the introduction period include MultiLang and version control. Architectural changes like migration to MgdSchema can be handled separately.