ArchivesReleaseMethod
Archives : Release method
Kept here for reference only, see our current release method for up-to-date information.
Generic road map for major releases
The main purpose here is to enable the dev. team to issue the next release at the time decided right after the previous one is out. To avoid any last-minute change situation, or ever postponed delivery for some bugs / features, we need to agree on a bug / feature / task list long before the release, freeze this list and strongly stick to it. It is stated here that the release date is more important than any of the items that were initially planned for this release: as the release date comes closer, we are thus ready to abandon any previously accepted items in order to complete the schedule.
The following generic road map is based on Mart's first proposal (see below, as a reference), and is still open to discussions, but will have to be completed and accepted by everyone by the end of March 2010. It will be used after the 1.4.0 is out.
Preliminary definitions
- previous (major) version : M.m.0
- next (major) version : M.m+1.0 or M+1.0.0
- item : bug / task / feature from the wish list
- publication : each item has to be described in detail in a dedicated wiki page ; this description must include :
- current state : how the current code/artwork fulfills the item ; what's this bug ; ...
- specification : what (not how!) we want to get in the end
- design : how we want to implement the item ; the preliminary design enables us to estimate the amount of work and set up a reasonable delivery date ; multiple options may have to be examined and compared before deciding which will be implemented ... all of this should be put here in order any developer / artist can understand what's going on, and may be one day also work on this item (in case it is needed or if an original sub-team member fails to comply for any reason).
- step buy step and fall back scenarios : items that could imply long and difficult work have to propose a step by step development plan, carefully checking that the code / artwork is in a consistent and deliverable state at the end of each step (or simply "hidable" / inhibitable in case no time to finish for the release)
- when the sub-team has decided how it would implement the item, they create as many tickets as necessary in Trac in order to divide the work in elementary steps achievable by 1 developer/artist in a reasonable amount of time if possible (no need for very small sub-tasks though, only for here for schedule tracking).
- sub-team : 1 to N artists/developers from the team (may be also people outside the project if needed) who volunteer for working on a particular item ; each sub-team is considered autonomous and works as a sub-project ; it cooperates with the other sub-teams in order to complete the common goal : the next release.
- director : each sub-team has 1 and only 1 director (mandatory),
- who is responsible for the whole item work, from the specification step to the end of beta tests ;
- he's the sub-project leader for the item, responsible for technical developments as well as the schedule and the communication with the other sub-teams;
- the whole dev team totally trusts him for the delivery of the item with expected quality and schedule.
- vote for priorities : as a first step to sort out the items we want to actually achieve, we organize a vote where each volunteer (dev. team or very close to it) gives a priority (1 = must-have ; 2 = needed, good idea ; 3 = no need) to each item (Artist ones, Developer ones, Car tuner ones and also remaining bugs in Trac) and tells if he volunteers for working on it (no time limit nor particular role for the moment). Here's a simple solution to organize the vote, based on the trust we all have on the vote master (one of us) :
- The vote master sets up a spreadsheet
- with 4 sheets : Artist tasks/features, Developer task / features, Car tuner task / features and remaining Trac bugs.
- with 4 columns in each sheet : Item id, item title, item priority (from 1=must-have, to 3=no need) and "Volunteer for working on it : Yes/No"
- The vote master votes on his side.
- The vote master sends the "empty" (no vote) spreadsheet to all the volunteers.
- Each volunteer votes and sends his spreadsheet to the vote master.
- The vote master builds up (and publishes) the final spreadsheet after gathering everyone's vote : the same spreadsheet as the original one, but where the votes have been summed (3rd column) and the volunteer names have been collected (4th column) for every item. The final spreadsheet also holds an unmodified copy of each voters vote, for transparency.
- more robust voting method (not used for the moment) : in case we couldn't trust in the vote master, the above method could be changed the following way : after voting (vote master or anyone else), everyone would password encrypt his vote spreadsheet and publish it to everyone ; after everyone has published his protected vote, he publishes his password, in order everyone can check everyone vote ... and check the final result spreadsheet.
- interpretation of the vote results (a first proposal, taking care that the #1 priority is "release 2.0 on time", but the #2 one is that everyone works on things he enjoys):
- high priority tasks with enough volunteer workers will probably not be a problem,
- high priority tasks with unsufficient sub-team will probably be removed, unless more volunteers come from other abandoned tasks,
- low priority tasks with enough volunteer workers could be kept, but as background works, only for spare time, and with special care of being quickly able to remove / hide the changes in code / art work in case not enough time to finish,
- low priority tasks with unsufficient sub-team would surely be removed.
Generic road map
Variable
Date
Description
A
Release date of previous major version and start of the real work on the item wish list for the next major version
A + 4 weeks
Total freeze of the item wish list for the next version : NOTHING can be added to the list. Items can be removed later if there is a majority for it or the release schedule will not be achieved without it. Start organizing a vote for defining priorities and building the working sub-teams (1 for each item)
A + 5 weeks
Priorities are set and frozen. Sub teams have decided for a director. Items with no or non sufficient sub-team are removed from the list, as well as those with no director. The item wish list become the item list. Each team starts analyzing the associated item, and publish its thoughts in the wiki (description / current state, specifications = what, primary design = how, in order to estimate a reasonable delivery date, after really thinking about it). The sub-teams discuss with each other to determine the dependencies between the items
A + 8 weeks
The detailed road map is frozen : items that will be achieved, items that won't, dependencies between the items, estimated delivery date for each item, associated sub-team with its director. The real development work can start
Monthly, between A and B
In the monthly meetings, each current item is discussed at least for schedule questions : will it be on time or not ; if any issue, a fall back solution is decided or planned to be decided ; may imply stopping the devs on this item or some other and remove it from the release
B
All the items from the item list are at least 99 % implemented ; those which are not ARE removed from the release, or left as is if acceptable for the users
B + 2 weeks
Total task / feature freeze ; no more development on task or features, only bug fixes
B + 3 weeks
First alpha release ; means every member of the team starts running tests and fix bugs as soon as possible, even if this means stopping his nice developments for things after the target major release
C
Release beta 1 (all main known bugs are solved)
C + 3 weeks
Release beta 2 (unless there is no need for it
C + 6 weeks
Release beta 3 (repeat releasing beta's until all bugs scheduled for 2.0.0 are resolved
D
Release rc 1 (can be skipped )
D + 2 weeks
Release rc 2 only if that is necessary
E
Release
F
E + N weeks
Patch release M.m+1.1 or M+1.0.1, only if major bugs discovered ; may include fixes for other annoying bugs if not too risky (filed as minor, but close to a major one)
G
F + P weeks
Patch release M.m+1.2 or M+1.0.2, only if ... etc ...
Older generic road map (as a reference)
As a reference, here's the initial release schedule that Mart had proposed on the mailing list.
Variable
Date
Description
A
Release date of 1.4.0
A + 1 month
Freeze of task / features list for 2.0: nothing can be added to the list. Items can be removed if there is a majority for it.
B
All features on the bug feature list are at least 90 % implemented
B + 2 weeks
Total feature freeze
B + 3 weeks
First alpha release
C
Release beta 1 (all main known bugs are solved)
C + 3 weeks
Release beta 2 (unless there is no need for it
C + 6 weeks
Release beta 3 (repeat releasing beta's until all bugs scheduled for 2.0.0 are resolved
D
Release 2.0.0 rc 1 (can be skipped )
D + 2 weeks
Release 2.0.0 rc 2 only if that is necessary
E
Release 2.0.0
E + 5 weeks
Release 2.0.1
E + 12 weeks
Release 2.0.2
