Changes between Version 25 and Version 26 of Release/Schedule
- Timestamp:
- 05/05/20 20:06:12 (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Release/Schedule
v25 v26 25 25 === Scenario 2 === 26 26 27 WIP28 29 27 Meta: 30 28 … … 33 31 * Current and present simple tense may refer to the suggested state. ("[On this scenario,] We have...", "...current release...") 34 32 * Versioning is still `major.minor.patch` (aka `major.minor.point`) and //more// or less semantic versioning. 33 * Even minor versions mark stable releases. Odd minor version mark development version and thus never have a patch number assigned and are never released. 35 34 36 35 In general: 37 36 38 37 * We have only one actively updated, maintained, and supported release series. 39 * Once a new major or minor version is released, the old release series goes to (low) maintenance mode and no further released are planned. 38 * Once a new major or minor version is released, the old release series goes to (low) maintenance mode and no further released are planned. 39 * There is no concept of long-term-support or old stable releases (LTR, LTS). 40 * If you need "that good and old" release, you are in the best position to evaluate which one that is in your case based on what you are using now, how widely you deployed it, etc. If you need fixes or other support for the version you picked, you can always provide these upstream yourself or pay somebody to do that (we are willing to accept/merge fixes). 40 41 * All minor versions within one major version series (e.g., 7.0 and 7.8) are compatible with each other in the sense that when you create a database in one with default settings it will work in the other with default settings. 41 42 * For example, you can create a new topology format, but by default, the old one needs to be used by default. 42 * 43 * This is the reason why we can't release 7.10 because master already contains a change of temporal database which is not backwards compatible. 43 44 44 45 !Versions/Releases/Builds: … … 46 47 * Latest release: 47 48 * This is the supported version users should install. 49 * Daily builds: 50 * Daily builds of development version from master. 51 * Daily builds of current release branch. 52 * These could replace what are now RCs. 53 * Unclear: Builds of the latest state of the old release branches. 48 54 * Maintenance releases: 49 55 * Release of the latest minor version for all/any of the other release branches, i.e., release branches in the maintenance mode. 56 * These are the old releases. 57 * Additionally, these could be also the maintenance (unplanned) releases if these are needed. 50 58 * These versions (series/branches) are no longer actively updated, but are updated on demand, i.e., if you submit a patch to fix a bug, we will likely accept it and create a new release when there is enough changes accumulated. 51 59 * There are two main use cases distros and large organizations. 52 60 * For example, the version in Ubuntu 18.04 is 7.4, so there might be a next patch release in the 7.4 series. 53 61 * These are announced only together with the next [latest?, supported?] release to avoid confusion in what is the latest release. 54 * Daily builds:55 * Daily builds of development version from master.56 62 57 Git and branches:63 Branches and tags: 58 64 59 65 * We have 3 kinds of branches: … … 62 68 * Current release: That's always one and only one latest release branch. 63 69 * This receives only bug fixes. 64 * Maintenance: That's all the other release branches. 70 * Maintenance: That's all the other release branches, i.e., the old release branches (branches of old releases). 71 * Minor release series are branches. 65 72 * Releases are tags on release branches. 66 73 74 Backporting and freezing: 75 76 * Once a release branch is branched out, only fixes can be made on that branch. 77 * Backporting is then done only to fix bugs. 78 * Unclear: What is a bug fix and what is a feature? If that X never worked is making X work a bug fix or a feature? Furthermore, how invasive can be a backport? (For example, fixing a lot of memory leaks or incompatibilities with a new library version.) 79 * In other words, at one point, there is a feature freeze which takes the state of master and makes it a release branch. New development still happens in the master, but the newly created release branch now receives only fixes. 80 81 Schedule (dates tentative): 82 67 83 ||= **Release** =||= **Planned date** =||= **Remarks** =||= **Important external releases** =|| 68 || 7.8.3 || May 2020 || || May 2020: GDAL 3.1.0 || 69 || 7.6.2 || May 2020 || last release, EOL || June 2020: QGIS 3.14.0 || 70 || 7.8.4 || Sep 2020 || last release, EOL || || || 71 || 8.0.0 || Nov 2020 || before: 80 branch forked from master || || 72 || 8.0.1 || Mar 2021 || || || || 73 || 8.0.2 || Jul 2021 || || || || 74 || 8.0.3 || Nov 2021 || || || || 75 || 8.2.0 || Dec 2021 || before: 82 branch forked from master || || || 84 || 7.8.3 || May 2020 || || May 2020: GDAL 3.1.0, June 2020: QGIS 3.14.0 || 85 || 7.8.4 || Sep 2020 || last release == EOL for 7.8 series || || 86 || 8.0.0 || Nov 2020 || some time after 7.8.4 and before this: 80 branch forked from master || || 87 || 8.0.1 || Mar 2021 || || || 88 || 8.0.2 || Jul 2021 || || || 89 || 8.0.3 || Nov 2021 || || || 90 || 8.2.0 || Dec 2021 || some time after 7.0.3 and before this: 82 branch forked from master || || 76 91 92 * One already existing exception is 7.6.2 (May 2020) which would be the last release of 7.6 series to formalize its end before the transition to the new system. More generally, it could be an example of a release wanted and contributed by a smaller group. 77 93 === Scenario 3 === 78 94
