[GRASS-dev] [release planning] GRASS GIS 8.0.0

[Markus Neteler]

On Wed, Jan 12, 2022 at 4:52 PM Vaclav Petras <wenzeslaus at gmail.com> wrote:
>
> On Tue, Jan 11, 2022 at 12:52 PM Veronica Andreo <veroandreo at gmail.com> wrote:
> >
> > El dom, 9 ene 2022 a las 16:36, Markus Neteler (<neteler at osgeo.org>) escribió:
> >>
> >> Can we now publish "final" or do we still need a RC2?
> >
> > With no blockers, I'd be in favor of publishing final already :)
> > Is there any "policy" regarding the number of RC's before final?
>
> Traditionally, I think we did 2 RCs, but since we are releasing from a ("stable") branch rather than the main (development) branch, one could argue we don't need any RCs at all. Perhaps 8.0.0 and all x.0.0 would be an exception requiring one RC since the branch is new(ly created from the main branch).

In this actual case I suggest to check what actually changed after RC1:

# go via "tag"
https://github.com/OSGeo/grass/releases/tag/8.0.0RC1
--> 19 commits to releasebranch_8_0 since this release
     --> https://github.com/OSGeo/grass/compare/8.0.0RC1...releasebranch_8_0
          --> list of changes

> We have a RFC with two RCs [1], but I think since then we considered reducing that (I can't find the wiki page with the notes).
>
> [1] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

It is still:
      Status: Late draft (7 Jan 2015)
so we may adapt and approve it in the PSC.

> On Tue, Jan 11, 2022 at 1:39 PM Newcomb, Doug via grass-dev <grass-dev at lists.osgeo.org> wrote:
> >
> > There may be some work to be done on the Windows standalone installer yet.
>
> At the New Year's call, we discussed a little bit that with a release, we may focus on the source code readiness for a release, but more or less ignore the distribution of the software. In other words, we would leave out the complexities of distributing the software from the event of tagging the source code with a release tag. On the other hand, the Windows installer code lives in the main source code, so as a result any changes may trigger a new patch release if we ignore the standalone installer when tagging. In any case, small issues in the installer are not blockers of the release.
>
> In an ideal world, the Windows installer is built automatically based on the event of tagging the release and the same happens for each commit on the branch for testing purposes. This can be achieved with the installer code in the main repo or in the separate repo in case a separate repo would clear up some issues with releasing.

If I'm not wrong, there is a draft PR for that:
https://github.com/OSGeo/grass/pull/1212

Markus