Release Cycle
From OpenSimulator
| (8 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
| − | {{Quicklinks}} | + | {{Quicklinks|Release Cycle}} |
<br /> | <br /> | ||
| Line 11: | Line 11: | ||
On Git, at the release point, we; | 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 | * create a new branch with the code to release and names as the release version, for example 0.9.2.0 | ||
| − | * change version information on the needed source files (VersionInfo.cs, ServerReleaseNotesURL | + | * on the release branch, change the version type to Release in the VersionInfo.cs |
| − | * add a tag with the new version with Dev suffix, for example 0.9.2.1Dev | + | * 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 | ||
Latest revision as of 02:23, 4 December 2023
 |
Languages: |
|
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
- 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
