'This content is deprecated. Please refer to the BuildStream website.'
This is the first iteration of a page which has been created as a dedicated page for all things release related, including:
- The beginnings of a a guide / checklist for maintainers
- Planned Release schedule
- Documenting of steps to making a release, what mailing lists it should be announced on, how to bump the versions and branch/tag accordingly, etc
Many of the above are currently still TODO (as of October 2017) but we'll add them here once they are clearer.
Release Schedule
Summary of discussion from monthly irc meeting, October 17 2017:
Alignment with GNOME Release Schedule
BuildStream releases will not be tethered with GNOME releases.
We'll try to follow the GNOME release schedule for our stable releases, but GNOME releases need not be blocked on BuildStream in general.
- Following the GNOME schedule is strongly encouraged but doesn't matter a great deal in reality.
BuildStream will target the *next* GNOME release (I think 3.30) as our second stable
BuildStream will follow GNOME style release numbering: ie. even minor number = stable, odd minor number = devel
Build up to a release
We should go for: API freeze one month before code freeze, and then release.
This means we can develop an internal model where we:
- Land bigger features early in the cycle...
- Reject features after a feature freeze...
- Leave us some time to address issues before release, without new features landing
Length of support of buildstream releases
We should continue to backport bug fixes to our stable branches, for the stable versions which are still required by GNOME maintained modulesets "at least" as far back as maintained GNOME stable releases go.