Release Cycle
From OpenSimulator
(Difference between revisions)
(Added Flavour to spice things up) |
|||
| Line 3: | Line 3: | ||
<br /> | <br /> | ||
| − | This is the current | + | This is the current OpenSim lightweight Release Cycle recipe. |
The goal is to run a cycle that churns out recommended code snapshots with reasonably regular intervals, and with a minimum of work for any one human resource. It should be a community effort, and anyone should be able to move the cycle forward. | The goal is to run a cycle that churns out recommended code snapshots with reasonably regular intervals, and with a minimum of work for any one human resource. It should be a community effort, and anyone should be able to move the cycle forward. | ||
| Line 12: | Line 12: | ||
<ol> | <ol> | ||
<li>Developers and Testers work on <em>/trunk</em> ("testers" being defined as "users feeding off trunk", also lovingly known as "trunkheads")</li> | <li>Developers and Testers work on <em>/trunk</em> ("testers" being defined as "users feeding off trunk", also lovingly known as "trunkheads")</li> | ||
| + | <li>/trunk revisions will always have the <i>Flavour</i> "Dev" reflected in the version info string. | ||
<li>Developers and Testers identify suitable release candidate revisions, from the repository history. (for example, people on [http://osgrid.org/ osgrid.org] discuss this on their weekly meet-ups)</li> | <li>Developers and Testers identify suitable release candidate revisions, from the repository history. (for example, people on [http://osgrid.org/ osgrid.org] discuss this on their weekly meet-ups)</li> | ||
| − | <li>This revision is branched off as a "release candidate" (to <em>/branches/0.6.5-rc1</em> in this case), | + | <li>This revision is branched off as a "release candidate" (to <em>/branches/0.6.5-rc1</em> in this case), version number is upped, flavour is changed to "rc1". Version number and flavour changes and committed <em>only to this branch</em>. We don't want to up the version number in trunk until we know we have a release.</li> |
<li>Testers now switch their focus to running the rc until they can give feedback on whether "rc <strong>sux</strong>" or "rc <strong>rox</strong>". | <li>Testers now switch their focus to running the rc until they can give feedback on whether "rc <strong>sux</strong>" or "rc <strong>rox</strong>". | ||
Key issues: | Key issues: | ||
| Line 25: | Line 26: | ||
<li>If any <span style="text-decoration: underline;">critical but fixable</span> errors are found, these are fixed in trunk and the fixing revision is merged into the release candidate branch. (or vice versa, if that works out better)</li> | <li>If any <span style="text-decoration: underline;">critical but fixable</span> errors are found, these are fixed in trunk and the fixing revision is merged into the release candidate branch. (or vice versa, if that works out better)</li> | ||
<li>If, even after this, testers agree that "rc sux" the project goes back to 1) to wait and look for the next rc (thusly named rc2)</li> | <li>If, even after this, testers agree that "rc sux" the project goes back to 1) to wait and look for the next rc (thusly named rc2)</li> | ||
| − | <li>If testers agree that "rc rox" the current rc | + | <li>If testers agree that "rc rox" the flavour of the current rc branch Flavour is changed to "Release", and this is tagged as "-release" (to <em>/tags/0.6.5-release</em> in this case)</li> |
| − | <li>The "-rc1" branch is renamed to "-post-fixes" (to <em>/branches/0.6.5-post-fixes</em> in this case) for continued service awaiting the next cycle. The svn rename lets us keep the revision history back thru the rc branch history.</li> | + | <li>The flavour of the "-rc1" branch is then changed to "Post_Fixes" and after this renamed to "-post-fixes" (to <em>/branches/0.6.5-post-fixes</em> in this case) for continued service awaiting the next cycle. The svn rename lets us keep the revision history back thru the rc branch history.</li> |
| − | <li>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)</li> | + | <li>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) - but the Flavour is kept at "Dev" in the trunk.</li> |
<li>The project goes back to 1)</li> | <li>The project goes back to 1)</li> | ||
</ol> | </ol> | ||
| − | The output of this would be named | + | The output of this would be named version flavours for each of these user categories: |
<ul> | <ul> | ||
<li><strong>Grid/Region owners running services in production</strong> | <li><strong>Grid/Region owners running services in production</strong> | ||
| Line 39: | Line 40: | ||
| − | Feed off <em>/trunk</em>, or off - | + | Feed off <em>/trunk</em> ("Dev"), or off -rcX or -post-fixes if they want some stability while hunting bugs or doing protoyping.</li> |
<li><strong>Testers</strong> | <li><strong>Testers</strong> | ||
| − | Testers are committed to helping the devs find bugs at the prize of instabilities, crashes and loss of data. They therefore feed off the <em>/trunk</em> development branch or - | + | Testers are committed to helping the devs find bugs at the prize of instabilities, crashes and loss of data. They therefore feed off the <em>/trunk</em> ("Dev") development branch or -rcX depending on whether there is an RC pending release or not. (ie, is the latest version an RC, use that, if not, use <em>/trunk</em>) |
Everyone feeding off <em>/trunk</em> are collectively labeled 'testers', and any installation running on anything but a 'release' or 'post-fixes' revision is considered a 'test installation'.</li> | Everyone feeding off <em>/trunk</em> are collectively labeled 'testers', and any installation running on anything but a 'release' or 'post-fixes' revision is considered a 'test installation'.</li> | ||
</ul> | </ul> | ||
Revision as of 13:07, 26 May 2009
 |
Languages: |
|
This is the current OpenSim lightweight Release Cycle recipe.
The goal is to run a cycle that churns out recommended code snapshots with reasonably regular intervals, and with a minimum of work for any one human resource. It should be a community effort, and anyone should be able to move the cycle forward.
If you're not acquainted with svn revision numbering schemes, see On revisions, tags and branches for additional info.
The Cycle:
- Developers and Testers work on /trunk ("testers" being defined as "users feeding off trunk", also lovingly known as "trunkheads")
- /trunk revisions will always have the Flavour "Dev" reflected in the version info string.
- Developers and Testers identify suitable release candidate revisions, from the repository history. (for example, people on osgrid.org discuss this on their weekly meet-ups)
- This revision is branched off as a "release candidate" (to /branches/0.6.5-rc1 in this case), version number is upped, flavour is changed to "rc1". Version number and flavour changes and committed only to this branch. We don't want to up the version number in trunk until we know we have a release.
- Testers now switch their focus to running the rc until they can give feedback on whether "rc sux" or "rc rox".
Key issues:
- Has all version numbers been updated?
- Does it play well with last version? Do we need to up the interface version as well?
- Does it feel better or worse than last version?
- Any critical errors that needs fixing first?
- If any critical but fixable errors are found, these are fixed in trunk and the fixing revision is merged into the release candidate branch. (or vice versa, if that works out better)
- If, even after this, testers agree that "rc sux" the project goes back to 1) to wait and look for the next rc (thusly named rc2)
- If testers agree that "rc rox" the flavour of the current rc branch Flavour is changed to "Release", and this is tagged as "-release" (to /tags/0.6.5-release in this case)
- The flavour of the "-rc1" branch is then changed to "Post_Fixes" and after this renamed to "-post-fixes" (to /branches/0.6.5-post-fixes in this case) for continued service awaiting the next cycle. The svn rename lets us keep the revision history back thru the rc branch history.
- 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) - but the Flavour is kept at "Dev" in the trunk.
- The project goes back to 1)
The output of this would be named version flavours for each of these user categories:
- Grid/Region owners running services in production Feed off "-post-fixes" if they want stability first, or off "-release" if they want a known 'upgrade track'.
- Developers Feed off /trunk ("Dev"), or off -rcX or -post-fixes if they want some stability while hunting bugs or doing protoyping.
- Testers Testers are committed to helping the devs find bugs at the prize of instabilities, crashes and loss of data. They therefore feed off the /trunk ("Dev") development branch or -rcX depending on whether there is an RC pending release or not. (ie, is the latest version an RC, use that, if not, use /trunk) Everyone feeding off /trunk are collectively labeled 'testers', and any installation running on anything but a 'release' or 'post-fixes' revision is considered a 'test installation'.
