Release Cycle
From OpenSimulator
(Difference between revisions)
| Line 19: | Line 19: | ||
# '''Change the wiki pages''' to point to new release. This includes both the download page and the link on the front page. | # '''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 | # '''Change the version type''' to Post_Fixes | ||
| + | |||
| + | == Next Release == | ||
| + | |||
| + | [[0.7 Planning]] | ||
Revision as of 19:57, 25 March 2010
 |
Languages: |
|
OpenSim 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.
Here are the release cycle steps
- Get informal feedback about current OpenSim stability. A good place to do this is the OpenSim weekly developer's meeting on osgrid.org.
- Announce the intention to start a release process to the opensim-dev mailing list.
- Branch <release name>-post-fixes from OpenSim 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 OpenSim trunk to the next possible future release (e.g. 0.6.9 if this release process concerns 0.6.8).
- 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 OpenSim 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
