Release Schedule

The scope is to release new GRASS GIS versions at a more regular schedule.



Scenario 1

Release Planned date Remarks GitHub milestone Important external releases
7.8.3 May 2020 GH 7.8.3 May 2020: GDAL 3.1.0
7.6.2 May 2020 last release, EOL GH 7.6.2 June 2020: QGIS 3.14.0
7.8.4 Sep 2020 GH 7.8.4
7.10.0 Nov 2020 forked from master
7.8.5 Jan 2021
7.10.1 Mar 2021
7.8.6 May 2021 last release, EOL
7.10.2 Jul 2021
7.10.3 Nov 2021
8.0.0 Dec 2021 forked from master GH 8.0/7.10

Scenario 2


  • Terminology is open to discussion, so please suggest if any term could be more clear.
  • When reading, please don't just assume that, e.g., stable, means what you think it means, but see how it is defined here or used in the context; ask for clarification if needed.
  • Current and present simple tense may refer to the suggested state. ("[On this scenario,] We have...", "...current release...")
  • Versioning is still major.minor.patch (aka major.minor.point) and more or less semantic versioning.
  • Even minor versions mark stable releases. Odd minor version mark development version and thus never have a patch number assigned and are never released.

In general:

  • We have only one actively updated, maintained, and supported release series.
  • Once a new major or minor version is released, the old release series goes to (low) maintenance mode and no further released are planned.
  • There is no concept of long-term-support or old stable releases (LTR, LTS).
    • 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).
  • 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.
    • For example, you can create a new topology format, but by default, the old one needs to be used by default.
    • 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.


  • Latest release:
    • This is the supported version users should install.
  • Daily builds:
    • Daily builds of development version from master.
    • Daily builds of current release branch.
      • These could replace what are now RCs.
    • Unclear: Builds of the latest state of the old release branches.
  • Maintenance releases:
    • Release of the latest minor version for all/any of the other release branches, i.e., release branches in the maintenance mode.
      • These are the old releases.
      • Additionally, these could be also the maintenance (unplanned) releases if these are needed.
    • 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.
    • There are two main use cases distros and large organizations.
      • For example, the version in Ubuntu 18.04 is 7.4, so there might be a next patch release in the 7.4 series.
    • These are announced only together with the next [latest?, supported?] release to avoid confusion in what is the latest release.

Branches and tags:

  • We have 3 kinds of branches:
    • Development: That's only the master branch.
      • This contains all the latest fixes and features (which were merged).
    • Current release: That's always one and only one latest release branch.
      • This receives only bug fixes.
    • Maintenance: That's all the other release branches, i.e., the old release branches (branches of old releases).
  • Minor release series are branches.
  • Releases are tags on release branches.

Backporting and freezing:

  • Once a release branch is branched out, only fixes can be made on that branch.
    • Backporting is then done only to fix bugs.
      • 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.)
  • 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.

Schedule (dates tentative):

Release Planned date Remarks Important external releases
7.8.3 May 2020 May 2020: GDAL 3.1.0, June 2020: QGIS 3.14.0
7.8.4 Sep 2020 last release == EOL for 7.8 series
8.0.0 Nov 2020 some time after 7.8.4 and before this: 80 branch forked from master
8.0.1 Mar 2021
8.0.2 Jul 2021
8.0.3 Nov 2021
8.2.0 Dec 2021 some time after 7.0.3 and before this: 82 branch forked from master
  • 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.

Scenario 3

A scenario taking into account issues with stabilization of G8

Version Date Comment
7.8.3 May 2020 Last G7 release with significant backports
7.8.4 Sep 2020 Just really minor stuff — no significant backports
8.0.0 Oct 2020 Release for early adopters
8.0.1 Dec 2020 Just minor fixes (mostly packaging related)
7.8.5 Jan 2021 Just really minor stuff for minor issues in LTS distros
8.2.0 Mar 2021 Still for early adopters
7.8.6 May 2021 ibid.
8.2.1 May 2021 Just minor fixes (mostly packaging related)
7.8.7 Sep 2021 Yes, this still supports Python 2
8.4.0 Oct 2021 First 8 for everyone

External release schedules

GRASS GIS versions in the various Linux distros

Former procedures and suggestions for GRASS GIS

Last modified 18 months ago Last modified on Jul 24, 2020, 12:03:37 AM