Release Plan

This report was contributed by by Cornelius Schumacher

Even before the meeting there was consensus within the kdepim team that a separate release of kdepim shortly after 3.2 would be useful to deliver the features which weren't completely ready for 3.2. There was a session to discuss this release at the meeting, followed by an IRC meeting including some of the people not present in Osnabrueck.

Cornelius presented a proposal for a release plan:

At Osnabrueck we discussed the next kdepim release after 3.2. There was a wide
agreement that it makes sense to do a separate release of kdepim soon after
3.2 idependently of the rest of KDE to deliver the features which were almost
ready for 3.2 but finally didn't make it into 3.2.

Key features we would like to include in the separate kdepim release are:
- Kolab client
- KitchenSync (Syncing calendar and addressbook between desktops)
- HTML mail composing
- KPilot integration into Kontact
- Client-side IMAP filtering
- Connection of Kontact to eGroupware

The propsal is to make this a feature-driven release by starting the release
cycle when four of the six key features are implemented. The estimated time
frame for this would be end of February.

The release cycle would look like this:

x: Start of release cycle triggered by completion of four of six key features
x + 2 weeks: feature freeze, branch, alpha release
x + 5 weeks: beta 1
x + 7 weeks: rc1, message freeze
x + 9 weeks: stable release, documentation freeze, merge to HEAD
x + 13 weeks: i18n release + critical bug fixes

If required we can add additional betas or release candidates delaying the
subsequent steps. If all goes well, the release would happen somewhen in May.


To make it possible to release in the proposed way we need some additional
policies. All the people in Osnabrueck agreed on that:
- kdepim has to compile and run with the released stable 3.2 kdelibs, no
dependencies on changes in the kdelibs HEAD branch later than 3.2.
- kdepim has to be kept stable enough to be ready for an alpha release two
weeks after the feature completion criteria is met, that means no experiments
which will need a lot of time to become stable, but keeping the kdepim HEAD
branch in a usable state.

David proposed me to be the release coordinator for the separate kdepim
release, there were no objections to the proposal and I'm willing to do this
job.

Two questions were discussed in depth:

Versioning scheme for separate kdepim release

One proposal was to name it kdepim-3.3. In favour of this scheme is that it speaks for itself, it clearly indicates that the release is an update with new features, it fits to the way kdepim releases were done in the past and it would make packaging straight-forward.

Another proposal was to use a completely different name like Kontact 1.0. This would have made it clear that it is a separate release. It might also be better suited to avoid confusion of people looking for (non-existing) kdelibs-3.3 packages fitting to kdepim-3.3 packages. The concrete Kontact 1.0 name wouldn't be appropriate for all parts of kdepim, though.

We also discussed putting the new features in the 3.2.x branch, but this has the severe problems that it would break feature and message freeze in the stable branch, would introduce new bugs into the branch, would have a misleading versioning scheme (the minor release isn't used for feature updates up to now) and would eliminate the option to maintain a stable 3.2.x branch without the new features.

The conclusion and agreement was to go with the kdepim-3.3 name

Maintance of the 3.2.x branch

With a kdepim-3.3 release another branch is introduced which needs additional resources. The question came up if the 3.2.x would still be maintained under these conditions.

There are several reasons for maintaining the 3.2.x branch. This would be the more stable branch. Maintaining it wouldn't force people to upgrade to kdepim-3.3 with the new features (and new bugs). Some packagers will take up the official stable 3.2.x branch.

Against maintaining the branch speaks that it would be less effort to not do so and that packagers would have a clear recommendation what branch to use.

The conclusion and general feeling was that kdepim-3.3 development should happen in a separate branch in order to keep all options. How much effort is required to do that depends on who picks up which branch and how stability of the 3.3 branch develops.

Other issues and conclusion:

Adriaan proposed to offer some "Janitor" jobs for things like providing screenshots for documentation and volunteered to follow up on this proposal after the meeting.

During the IRC meeting we discussed some aspects of the release in some more detail. General consensus was to follow the proposals.

As result the kdepim-3.3 release plan was set up. This hopefully will result in a Kontact 1.0 release in May 2004.

| back to meeting overview |

[ Edit ]