<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Esteemed Colleagues,<BR>
 <BR>
With the 0.6.4 around the corner, I'd like to propose a small extension of the release tag/post-fixes branch scheme that has worked well for a couple of minor versions:<BR>
 <BR>
Basically, the flow is this:<BR>
 <BR>
1) Developers and Testers work on TRUNK (testers at this point being defined as 'users feeding off trunk')<BR>
 <BR>
2) Developers and Testers identify suitable release candidate revisions, from the repository history.<BR>
 <BR>
3) This revision is branched off as a 'release candidate' ("-rc1"), and the version number is upped and committed only to this branch.<BR>
 <BR>
4) Testers now switch their focus to running the rc until they can give feedback "rc sux" or "rc rox". Key issues:<BR>
  * Has all version numbers been updated<BR>
  * Does it play well with last version? Do we need to up the interface version as well?<BR>
  * Does it feel better or worse than last version?<BR>
  * Any critical errors that needs fixing first?<BR>
 <BR>
5) If testers agree that "rc sux" the project goes back to 1) wait and look for the next rc (rc2 et c)<BR>
 <BR>
6) If testers agree that "rc rox" the current rc revision is tagged as "-release".<BR>
 <BR>
7) The "-release" tag is branched to a "-post-fixes" branch for continued service awaiting the next cycle.<BR>
 <BR>
8) The version number (and optionally interface version) uppage is merged back into trunk. (this is a minor merge which will probably always succeed without conflict)<BR>
 <BR>
9) The project goes back to 1)<BR>
 <BR>
The output of this would be named revisions for each of these user categories:<BR>
 <BR>
== Developers ==<BR>
Feed off TRUNK, or off -rc or -post-fixes if they want some stability while hunting bugs or doing protoyping.<BR>
 <BR>
== Testers ==<BR>
Feed off TRUNK or -rc depending on whether there is an RC pending release or not. (ie, is the latest version an RC, use that, if not, use TRUNK)<BR>
 <BR>
== Grid/Region owners ==<BR>
Feed off "-post-fixes" if they want stability first, or off "-release" if they want a known 'upgrade track'.<BR>
<BR>I here choose to define region owners feeding off TRUNK as 'testers'.<BR><BR>
If I get no strong objections by monday 16th of March, I will update the versions and download pages to reflect this process.<BR>
 <BR>
I'm already on 4) as I just branched off /branches/0.6.4-rc1, so testers, please give it a spin.<BR>
 <BR>
It is my belief that this process would work well with how I understand the community is using the code, with a minimum of fuss. Please note that there is no real 'hardening' of release candidates, it's all based on back-tagging.<BR>
<BR>Best regards,<BR>Stefan Andersson<BR>Tribal Media AB<BR><BR></body>
</html>