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.
69 lines
2.7 KiB
69 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.
|
|
|