| | 1 | = Release Cycle for RoarAudio Main Package = |
| | 2 | This document is a draft description the release cycle for the RoarAudio Main Package. The other packages are updated in a much less strict fashion. |
| | 3 | |
| | 4 | NOTE: Everything is counted starting from zero not one. |
| | 5 | |
| | 6 | The package has a most outer cycle with so called major releases. Those releases consists only of a major and minor version number. For example: 0.3, 0.7, 1.3. There should roughly one major release per year. If a major release is out support for the second last major release is terminated. For example if 0.4 is released support for 0.2 is terminated. |
| | 7 | |
| | 8 | Between two major releases there are so called minor releases. Those have version numbers containing 'beta' or 'rc' like this: 0.4beta6, 0.8rc3. The order is as following: beta releases for a major release, rc releases for the major release and finally the major release. Fir example: ..., 0.8beta0, 0.8beta1, 0.8rc0, 0.8, ... Those minor release should be released about once every month. The last two should be rc releases but don't have to. |
| | 9 | |
| | 10 | Before any release is done there will be pre-releases. Pre-releases have 'pr' in the version number like this: 0.7beta8-pr4. A pre-release is announced as every other release. Everyone can object the release and the cycle is halted and the situation examined: The release manager will decide if the problem needs to be fixed before or after the release or can be fixed at all (willnotfix/unreproducible/invalid). The objection can officially be done by sending a mail to the mailing list or filing a bug to the bug tracker for the specific release (former is preferred) within two days (48 hours). If there is a valid objection the problem can be fixed and another pre-release is done or if the problem is very bad the release cycle can be terminated. The release manager will decide this. |
| | 11 | |
| | 12 | Two days after a objection-free pre-release the release manager is free to release the pre-release as release. Only very minor changes are allowed to do between those releases. This includes: Updating version number (removing -prX suffix), updating list of tested systems, typos in README file. |
| | 13 | |
| | 14 | The pre-release cycle exists so package maintainers and other users can test the release before the release and can report back problems with for example packaging for distribution. |
