735
edits
Release plan: Difference between revisions
Jump to navigation
Jump to search
no edit summary
mNo edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
{{Release}} | {{Release}} | ||
The '''release plan''' is the process by which a new version of [[FlightGear]] is released. The release plan is actually a continual work-in-progress, and is refined with every new release. | The '''release plan''' is the process by which a new version of [[FlightGear]] is released. The release plan is actually a continual work-in-progress, and is refined with every new release and how much available resource and interest is available. | ||
[[File:ReleasePlan.jpg|thumb|250px|The original release plan.]] | [[File:ReleasePlan.jpg|thumb|250px|The original release plan.]] | ||
FlightGear has had | FlightGear has had multiple release plans over [[FlightGear History|history]]. | ||
* Originally, releases were sporadic, irregular and took many months of manual preparation. | |||
* Subsequently a release plan was developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during [[LinuxTag]] 2011. | |||
* A more regular plan was proposed by Torsten Dreyer after the 3.6 release was [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|cancelled]]. | |||
* Currently "Long Term Support" (LTS) releases are generated every ~24 months, with intermittent "preview" between them. | |||
To suggest improvements and/or changes to the release plan, it is recommended to get in touch via the [[mailing list]]. Improvements can be based on the [[Release plan/Lessons learned|lessons learned]] from previous releases. | To suggest improvements and/or changes to the release plan, it is recommended to get in touch via the [[mailing list]]. Improvements can be based on the [[Release plan/Lessons learned|lessons learned]] from previous releases. However, do not underestimate the amount of effort go create a new release! Most of the burden falls on a few people. | ||
== General release concept == | == General release concept == | ||
At any given time there are two release "stream": | |||
* A Long Term Support (LTS) release stream. This is a stable release to which bug fixes are applied, and will be active for up to two years. Most users and aircraft developers use this release. Currently 2020.3. | |||
* A "preview" release, based on the development branch "next". This is for those interested in the latest developments. | |||
== Version numbers == | == Version numbers == | ||
FlightGear version numbers consist of three digits, separated by dots: | FlightGear version numbers consist of three digits, separated by dots: | ||
* '''Year''' (<u>2020</u>.1.0): The year the version was released. | |||
* ''' | * '''Number''' (2020.<u>1</u>.0): Which release of the year the version is. This will be an odd number. (Even numbers are used for development branches) | ||
* ''' | * '''Revision''' (2020.1.<u>0</u>): Indicates one of two things: | ||
** In the '''latest [[Git]] version''' or '''[[FlightGear build server|nightly build]]''', this digit is even, indicating that it is unstable. | |||
** | ** When a new '''release''' is created, this digit is incremented to an odd number. | ||
* ''' | |||
{{note|In general, release are referred to by their first two digits (e.g., 2020.3). However, when filing a bug report or debugging problems, it is a good idea to give the full release number.}} | |||
{{note|In general, release are referred to by their first two digits (e.g., 3 | |||
== Detailed time schedule and checklist == | == Detailed time schedule and checklist == | ||
# Just after | # Just after an LTS is generated, the next default airport is decided on by a poll on the forum. The next LTS release will be named after it. | ||
# | # A series of "preview" releases generated for cutting edge users. For each release: | ||
## A release branch is cut from "next". E.g. release/2021.1 | |||
# | ## The version files are incremented. On the next branch this increases to the next even number. E.g. 2021.2.0 | ||
# On the | ## Builds are generated. | ||
# | # When a new LTS preview is declared (after ~24 months): | ||
## A release branch is cut from "next". E.g. release/2022.1 | |||
## The version files are incremented. On the next branch this increases to the next even number. E.g. 2022.2.0 | |||
## Builds are generated for the preview LTS. | |||
## Additional branches are created for subsequent releases from the original release branch (e.g. release/2022.1 -> release/2022.3) | |||
## Fixes are merged into the release branch as well as "next" | |||
## Further builds and release are generated until an LTS is declared (e.g release/2022.3) | |||
The process is repeated after three months. | The process is repeated after three months. | ||
| Line 88: | Line 51: | ||
<!-- | <!-- | ||
== Bug fix committing policy == | == Bug fix committing policy == | ||
Fixes for bugs during the | Fixes for bugs during the preview release are applied to both "next" and the release branch (e.g. release/2022.2) | ||
'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch. | '''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch. | ||