AbiWord Developer Documentation
Release Strategy Outline
Proposal -- Draft
Disclaimer
This document is a first draft. I have certainly left out important parts of the release process. In addition, many numbers were chosen arbitrarily. Three days here and four days here. If you think these numbers are weird, please voice your concerns! Corrections are welcome.
If anything, this document should be a starting point for discussion. It is not set in any way set in stone.
Introduction
AbiWord developers tend to stress, among other things, the following two goals:
AbiWord is for everyone (cross-platform, cross-language)
AbiWord should “Just Work” for its users.
These are admirable goals, but are also difficult to accomplish. Each platform tends to require its own package management system, its own binaries, etc. Similarly, each language tends to require its own dictionary files and string tables.
This document intends to outline a release strategy that will allow for a maximization of both goals, without impeding progress.
Motivation
Why even write this document? I believe that standardizing the release procedures can be beneficial in a number of ways.
Even if this document becomes nothing more than a checklist, it will still be useful. For example, did you know that there is an abiword-announce mailing list? No? That’s probably because the last version of AbiWord which was announced on this list was version 0.7.14-2 back in April. This is pretty bad since we’ve accomplished so much since then. We can avoid this kind of slippage by having a reference to look at.
Moreover, a standardized release practice will be beneficial because it will prevent us from having to go through the same discussions over and over again with each release. It will prevent us from forgetting crucial steps in the release process, and it will identify priorities to be accomplished before a release is made.
Components of a Successful Release
There are several issues relevant to a release cycle. Here we attempt to identify many of them. The order has no meaning, it’s just alphabetical.
Announcements
Users should be informed of the availability of new releases. We should try to reach as many current users as possible, in addition to attracting as many new users as possible.
Package/Binary Availability
Binaries and packages/installers should be available for as many platforms as possible. Users should not have to compile the program by hand. It should be as easy as possible for users to find the right package.
Quality Assurance
The new version should not have any “blocker” class bugs, and should function as well as possible. This is not to say that the release can’t have bugs, just that it should have no major bugs.
Translation
Each release should be as fully translated as possible into all supported languages. Non-English users should not have to struggle with menu options and names in English. Dictionaries should be easy to find and download.
Proposed Release Strategy
1. Desire for a new release is realized
Developers realize that significant changes have been made (new features, fixed bugs, efficiency improvements, etc.) Someone suggests that a new release is in order.
2. Release is agreed upon
Developers agree that it’s time for a release. If there are significant objections, the objections are discussed and the release is possibly postponed. If no significant objections arise, then the release moves forward. Release Manager is chosen for this release.
3. String freeze date, branch date are chosen.
To promote Translation efforts, Release Manager chooses date for string freeze (no new user-visible strings to be added). String freeze should occur no more than three days after release is agreed upon, branch date should be four days after string freeze.
4. String freeze goes into effect, branch date chosen.
No new strings may be added during this period. Release Manager generates a report detailing how complete each translation is. Release Manager emails maintainers of incomplete translations and requests new strings within four days.
5. Pre-Branch bug days
Release Manager announces that the third and fourth day of the string freeze are mandatory “bug days.” Developers meet in IRC during these days and attempt to smash as many bugs as they can.
6. Branch Date Arrives. rc0 tagged, tested.
Release Manager tags CVS <version>-rc0.
Release Manager announces that strings are now un-frozen on main tree.
Designated release testers download rc0 and test on their platforms for three days. Problems are reported and classified as blocking or non-blocking. Bugs are resolved. If a blocking bug cannot be resolved, three-day testing time is extended to six-days. If blocking bug is cannot be resolved,
rc0 is aborted and we return to step 3.
7. rc0 passes testing, packaging commences.
Designated packagers create binary distributions and setup programs for as many target platforms as we possibly can. Packages are signed and uploaded to SourceForge. Packaging deadline is three days after rc0 passes testing.
8. Packages are in, release commences.
Release Manager lists sends release information to Webmaster, who updates web site to reflect new version.
Webmaster sends announcements to abiword-announce, abiword-dev and abiword-users.
Webmaster notifies designated freeware/shareware site liaisons of the release and instructs them to inform the sites they are responsible for.
Webmaster reports to Release Manager that release is out.
9. Release evangelism concludes the cycle
Release Manager informs cross-platform and platform-specific evangelists of the release, asks them to relay it to their advertising media.
Notes
From start to finish, a “smooth release” would require about 2 weeks to complete under this model. If this seems like a long time, note that it includes time for bug hunting, translating, testing, packaging, and distributing.
The proposed model also gives good flexibility in that it can be aborted up until step 8. This allows us to back out of a release easily.
For this model to work, we need to clearly establish who is/are our:
Release Manager
Can be fixed or chosen on a per-release basis
Programming experience not necessarily required, possibly helpful.
Translators
Need translators for each language we support.
Need to create a good database so that we can know “who to call”
Release Testers
Need good debugging skills, wide variety of platforms.
Possibly can double as release packagers.
Need to be able to compile AbiWord from CVS.
Release Packagers
Need familiarity with a package management system.
Needed for a wide variety of platforms.
Need to be able to digitally sign packages.
Webmaster
Programming experience not required.
Needs good writing skills, ability to update web site.
Site Liaisons
Programming experience not required.
Need good reliability, communications skills.
Need to make sure that the job gets done.
XP Evangelists
Programming experience not required.
Need to be able to communicate with high-traffic sites.
Platform Evangelists
Programming experience not required.
Need good familiarity with their platform’s hang-outs.
There is no reason that a single person cannot be cast more than one of these roles. But, as should be obvious, this is going to need to be a group effort to cover all of our translations and packaging needs.