The Meson Build System
http://mesonbuild.com/
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
64 lines
2.7 KiB
64 lines
2.7 KiB
# 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.
|
|
|