| # Release procedure |
| |
| **This page is WIP. The following procedure is not yet approved for use** |
| |
| # Trunk |
| |
| Meson operates under the principle that trunk should (in theory) be always |
| good enough for release. That is, all code merged in trunk must pass all unit |
| tests. Any broken code should either be fixed or reverted immediately. |
| |
| People who are willing to tolerate the occasional glitch should be able to |
| use Meson trunk for their day to day development if they so choose. |
| |
| # Major releases |
| |
| Major releases are currently in the form 0.X.0, where X is an increasing |
| number. We aim to do a major release roughly once a month, though the |
| schedule is not set in stone. |
| |
| Before a major release is made a stable branch will be made, and 0.X.0-rc1 |
| release candidate will be made. A new milestone for 0.X.0 will be made, and |
| all bugs effecting the RC will be assigned to this milestone. Patches fixing |
| bugs in the milestone will be picked to the stable branch, and normal |
| development will continue on the master branch. Every week after after this a |
| new release candidate will be made until all bugs are resolved in that |
| milestone. When all of the bugs are fixed the 0.X.0 release will be made. |
| |
| # Bugfix releases |
| |
| Bugfix releases contain only minor fixes to major releases and are designated |
| by incrementing the last digit of the version number. The criteria for a bug |
| fix release is one of the following: |
| |
| - release has a major regression compared to the previous release (making |
| existing projects unbuildable) |
| - the release has a serious bug causing data loss or equivalent |
| - other unforeseen major issue |
| |
| In these cases a bug fix release can be made. It shall contain _only_ the fix |
| for the issue (or issues) in question and other minor bug fixes. Only changes |
| that have already landed in trunk will be considered for inclusion. No new |
| functionality shall be added. |
| |
| # Requesting a bug fix release |
| |
| The process for requesting that a bug fix release be made goes roughly as follows: |
| |
| - file a bug about the core issue |
| - file a patch fixing it if possible |
| - contact the development team and request a bug fix release (IRC is the |
| preferred contact medium) |
| |
| The request should contain the following information: |
| |
| - the issue in question |
| - whether it has already caused problems for real projects |
| - an estimate of how many people and projects will be affected |
| |
| There is no need to write a long and complicated request report. Something like the following is sufficient: |
| |
| > The latest release has a regression where trying to do Foo using Bar |
| breaks. This breaks all projects that use both, which includes at least [list |
| of affected projects]. This causes problems for X amount of people and |
| because of this we should do a bugfix release. |
