Release Cycle

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(New page: This is the current (as of the 0.6.5 release) OpenSim lightweight Release Cycle recipe. The goal is to run a cycle that churns out recommended code snapshots with reasonably regular inter...)
 
 
(41 intermediate revisions by 10 users not shown)
Line 1: Line 1:
−
This is the current (as of the 0.6.5 release) OpenSim lightweight Release Cycle recipe.
+
__NOTOC__
 +
{{Quicklinks|Release Cycle}}
 +
<br />
  
−
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.
+
OpenSimulator has a lightweight release cycle right now. This allows us to get code out to people quickly, as befits the alpha status of the project.
  
−
If you're not acquainted with svn revision numbering schemes, see [[On revisions, tags and branches]] for additional info.
+
Since 0.9.1.0 we did simplify the release cycle even more, removing the release candidates and post fixes "things"
  
−
The Cycle:
+
We make a new release when the code state and received feedback justifies one.
−
<ol>
+
Changes on the minor number of the version will usually mean a release with mostly "bug fixes"
−
<li>Developers and Testers work on <em>/trunk</em> ("testers" being defined as "users feeding off trunk", also lovingly known as "trunkheads")</li>
+
On Git, at the release point, we;
−
<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>
+
* create a new branch with the code to release and names as the release version, for example 0.9.2.0
−
<li>This revision is branched off as a "release candidate" (to <em>/branches/0.6.5-rc1</em> in this case), and the version number is upped 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>
+
* on the release branch, change the version type to Release in the VersionInfo.cs
−
<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>".
+
* on master branch, change version information on the needed source files (VersionInfo.cs, ServerReleaseNotesURL in OpenSimDefaults.ini, etc)
−
Key issues:
+
* on master branch, add a tag with the new version with Dev suffix, for example 0.9.2.1Dev
−
<ul>
+
−
<li>Has all version numbers been updated?</li>
+
−
<li>Does it play well with last version? Do we need to up the interface version as well?</li>
+
−
<li>Does it feel better or worse than last version?</li>
+
−
<li>Any critical errors that needs fixing first?</li>
+
−
</ul>
+
−
</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 testers agree that "rc rox" the current rc revision 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 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 project goes back to 1)</li>
+
−
</ol>
+
−
The output of this would be named revisions for each of these user categories:
+
−
<ul>
+
−
<li><strong>Grid/Region owners running services in production</strong>
+
  
 +
update the release release notes page
  
−
Feed off "-post-fixes" if they want stability first, or off "-release" if they want a known 'upgrade track'.</li>
+
add a release notes page for the new version on wiki as ServerReleaseNotesURL
−
<li><strong>Developers</strong>
+
  
 +
Produce the release source and binary packages and place on the website at http://dist.opensimulator.org
  
−
Feed off <em>/trunk</em>, or off -rc or -post-fixes if they want some stability while hunting bugs or doing protoyping.</li>
+
Add the release and new version to Mantis versions field
−
<li><strong>Testers</strong>
+
  
 +
Update the rest of wiki so it points to the new release
  
−
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 -rc 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>
+
Run to a remote island without telephone or internet
−
</ul>
+
 
 +
 
 +
Here are the old release cycle steps
 +
 
 +
# '''Get informal feedback''' about current OpenSimulator stability. Good places to do this are at the OpenSimulator weekly developer's meeting on osgrid.org and in the #opensim-dev IRC channel.
 +
# '''Announce the intention''' to start a release process to the opensim-dev mailing list.
 +
# '''Branch''' <release name>-post-fixes from OpenSimulator Master in git. For example, 0.6.8-post-fixes.
 +
# '''Change the version type''' in VersionInfo in OpenSim.Framework.Servers to RC1.
 +
# '''Change the release number''' in OpenSimulator trunk to the next possible future release (e.g. 0.6.9 if this release process concerns 0.6.8).
 +
# '''Change ServerReleaseNotesURL''' in OpenSimDefaults.ini in OpenSimulator Master in git and create a new “under development” wiki release notes page as required.
 +
# '''Produce a binary package''' for the release candidate.
 +
# '''Create a field for release in Mantis'''
 +
# '''Gather feedback''' over 2 weeks or so. '''Make bug fixes''' if possible. Critical showstopper bugs (e.g. server won't start up) ''should'' be fixed.
 +
# '''Change the version type''' to Release
 +
# '''Produce OpenSimulator source and binary packages''' after a successful test period and '''place on the website''' at http://opensimulator.org webserver (this needs further documentation since the automated production process is currently broken).
 +
# '''Change the wiki pages''' to point to new release. This includes both the download page and the link on the front page.
 +
# '''Change the version type''' to Post_Fixes
 +
 
 +
==See Also==
 +
 
 +
* [[Release Procedure]]
 +
 
 +
[[Category:Development]]

Latest revision as of 02:23, 4 December 2023

Languages Languages: 

En.png English   De.png Deutsch


OpenSimulator has a lightweight release cycle right now. This allows us to get code out to people quickly, as befits the alpha status of the project.

Since 0.9.1.0 we did simplify the release cycle even more, removing the release candidates and post fixes "things"

We make a new release when the code state and received feedback justifies one. Changes on the minor number of the version will usually mean a release with mostly "bug fixes" On Git, at the release point, we;

  • create a new branch with the code to release and names as the release version, for example 0.9.2.0
  • on the release branch, change the version type to Release in the VersionInfo.cs
  • on master branch, change version information on the needed source files (VersionInfo.cs, ServerReleaseNotesURL in OpenSimDefaults.ini, etc)
  • on master branch, add a tag with the new version with Dev suffix, for example 0.9.2.1Dev

update the release release notes page

add a release notes page for the new version on wiki as ServerReleaseNotesURL

Produce the release source and binary packages and place on the website at http://dist.opensimulator.org

Add the release and new version to Mantis versions field

Update the rest of wiki so it points to the new release


Run to a remote island without telephone or internet


Here are the old release cycle steps

  1. Get informal feedback about current OpenSimulator stability. Good places to do this are at the OpenSimulator weekly developer's meeting on osgrid.org and in the #opensim-dev IRC channel.
  2. Announce the intention to start a release process to the opensim-dev mailing list.
  3. Branch <release name>-post-fixes from OpenSimulator Master in git. For example, 0.6.8-post-fixes.
  4. Change the version type in VersionInfo in OpenSim.Framework.Servers to RC1.
  5. Change the release number in OpenSimulator trunk to the next possible future release (e.g. 0.6.9 if this release process concerns 0.6.8).
  6. Change ServerReleaseNotesURL in OpenSimDefaults.ini in OpenSimulator Master in git and create a new “under development” wiki release notes page as required.
  7. Produce a binary package for the release candidate.
  8. Create a field for release in Mantis
  9. Gather feedback over 2 weeks or so. Make bug fixes if possible. Critical showstopper bugs (e.g. server won't start up) should be fixed.
  10. Change the version type to Release
  11. Produce OpenSimulator source and binary packages after a successful test period and place on the website at http://opensimulator.org webserver (this needs further documentation since the automated production process is currently broken).
  12. Change the wiki pages to point to new release. This includes both the download page and the link on the front page.
  13. Change the version type to Post_Fixes

[edit] See Also

Retrieved from "http://opensimulator.org/index.php?title=Release_Cycle&oldid=53782"
Personal tools
General
About This Wiki