A list for the developers of CellML tools

Text archives Help


[cellml-dev] Summary of today's discussion of 0.3 release strategy


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-dev] Summary of today's discussion of 0.3 release strategy
  • Date: Wed, 24 Oct 2007 13:00:03 +1300

Hi,

We are currently well past the planned three-monthly release cycle for
PCEnv (mainly because we were waiting for the recruitment of Justin to
complete, and for Justin to get up to speed with PCEnv development). As
this has now happened, we held a meeting today along the path towards
PCEnv 0.3. This didn't include Alan Garny (so please give any feedback
you may have), but Justin Marsh, Randall Britten, James Lawson and
myself were at the meeting.

Note that this applies to PCEnv and the CellML API - while they are
separate products they are both going through the process together.

We came up with a proposed timeline for when things happen - we will
start to put this into place unless we hear any major objections from
developers not at the meeting:
* As of today until the point that we branch, there are to be no new
features added on the trunk. The rationale for this is that we want to
focus the Auckland resources on fixing bugs rather than adding features,
and we don't believe that Alan is currently working on new features for
PCEnv (if he wants to, we could branch earlier, but we need to wait to
see what happens there).
* At any time, any 'major' regressions of 0.2 functionality should be
fixed - we can't make a release with such a problem.
* Until the 1st of November, fixes to features added before today but
after 0.2 can be checked in to the trunk without the need for pre-commit
discussion.
* After the 1st of November, all fixes to features added before today
but after 0.2 should be discussed on the tracker or mailing list first
before being committed to the trunk (or branch if we have merged). This
will give us (i.e. the developers collectively) the ability to decide if
we should drop the new feature or fix it. Providing an analysis of risk
together with a proposed course of action on the tracker item for each
individual issue would be helpful.
* At some point shortly after the merge, James (with the help of the
developers) will begin working on documenting PCEnv, and also on
creating functional tests in Litmus.
* Immediately prior to the branch, all functional tests will be run,
and the branch will be made only if they pass, otherwise we will go back
to a fix-retest iteration.
* After branching, release candidate 1 will be made.
* After the release candidate, the developers can go back to working
on features on the trunk.
* If no problems with the release candidate are found after a week, we
release it as final. Otherwise, we fix the problems on trunk and branch,
make a new release candidate, and repeat as for the first release candidate.

Best regards,
Andrew





Archive powered by MHonArc 2.6.18.

Top of page