[GRASS-dev] [release planning] GRASS GIS 8: create new release branch

GRASS GIS GRASS GIS developer
1

Hi devs,

Let me suggest to create a new release branch in the next two weeks
It will help us to focus on the upcoming and even announced 8.0.0
release: several conferences are upcoming with presentations on GRASS
GIS 8 talks and demo sessions.
So it makes quite sense to have a tangible version available, at least
in a release branch :slight_smile:

Now, the question is, also to avoid excessive cherry-picking of fixes
and changes from master (to be called 8.1 then), which of the open PR
may be merged soon?

See e.g. here:
https://github.com/OSGeo/grass/milestone/4

See also (please add notes!):
Draft release notes: https://trac.osgeo.org/grass/wiki/Grass8/NewFeatures80

Thanks,
Markus

2

On Fri, 14 May 2021 17:09:42 +0200
Markus Neteler <neteler@osgeo.org> wrote:

[...]

Now, the question is, also to avoid excessive cherry-picking of fixes
and changes from master (to be called 8.1 then), which of the open PR
may be merged soon?

#1237
#1421
#1569 (fixes #1420)
#1570 (fixes #1355)

These are all trivial bugfixes.

--
    Denis Ovsienko

3

On Fri, May 14, 2021 at 11:10 AM Markus Neteler <neteler@osgeo.org> wrote:

Let me suggest to create a new release branch in the next two weeks
…

Now, the question is, also to avoid excessive cherry-picking of fixes
and changes from master (to be called 8.1 then), which of the open PR
may be merged soon?

I actually expected that you would be a “beta” release, not an RC, marked by tagging a commit on master branch with the code as is. This would avoid any backporting, but perhaps, it is not creating enough focus for 8.0 and having a 8.0 branch gives more freedom in what goes into the master branch.

4

Denis,

On Fri, May 14, 2021 at 10:12 PM Denis Ovsienko <denis@ovsienko.info> wrote:

On Fri, 14 May 2021 17:09:42 +0200
Markus Neteler <neteler@osgeo.org> wrote:

[...]
> Now, the question is, also to avoid excessive cherry-picking of fixes
> and changes from master (to be called 8.1 then), which of the open PR
> may be merged soon?

#1237: parser: fixup more messages
--> looks good, will you merge it?

#1421 r.geomorphon: fix landform category names
--> I have added a comment, related to the HTML page content

#1569 (fixes #1420) r.in.poly: do not try to use stdin as input
#1570 (fixes #1355) r.geomorphon: remove multires-specific code
--> will you merge them?

These are all trivial bugfixes.
--
    Denis Ovsienko

Markus

5

On Sat, May 15, 2021 at 4:05 AM Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, May 14, 2021 at 11:10 AM Markus Neteler <neteler@osgeo.org> wrote:

Let me suggest to create a new release branch in the next two weeks
...

Now, the question is, also to avoid excessive cherry-picking of fixes
and changes from master (to be called 8.1 then), which of the open PR
may be merged soon?

I actually expected that you would be a "beta" release, not an RC, marked by tagging a commit on master branch with the code as is.
This would avoid any backporting,

Yes, that's an alternative idea.

but perhaps, it is not creating enough focus for 8.0 and having a 8.0 branch gives more freedom in what goes into the master branch.

Indeed, a full blown new release branch for G800 would open the master
branch for new (radical) changes.

@All: your opinion?

Markus

6

Hello Makrus et al.

2021-05-15 16:40 GMT+03:00, Markus Neteler <neteler@osgeo.org>:

On Sat, May 15, 2021 at 4:05 AM Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, May 14, 2021 at 11:10 AM Markus Neteler <neteler@osgeo.org>
wrote:

Let me suggest to create a new release branch in the next two weeks
...

Now, the question is, also to avoid excessive cherry-picking of fixes
and changes from master (to be called 8.1 then), which of the open PR
may be merged soon?

I actually expected that you would be a "beta" release, not an RC, marked
by tagging a commit on master branch with the code as is.
This would avoid any backporting,

Yes, that's an alternative idea.

but perhaps, it is not creating enough focus for 8.0 and having a 8.0
branch gives more freedom in what goes into the master branch.

Indeed, a full blown new release branch for G800 would open the master
branch for new (radical) changes.

@All: your opinion?

I would like to get PR #1501 (depends on #1272) into master before
branching as it is already quite large and disruptive.
It is almost ready (today I wrote first of three management
functions). I want to finish lib part before merging – management
module can be then created as a separate PR at some point later.

I would go with branching 8 off just before release. Do we have some
large PRs coming in for 8.1 that can not wait?

Markus

Māris.

https://github.com/OSGeo/grass/pull/1501

7

Hi all,

El jue, 20 may 2021 a las 17:21, Maris Nartiss (<maris.gis@gmail.com>) escribió:

Hello Makrus et al.

2021-05-15 16:40 GMT+03:00, Markus Neteler <neteler@osgeo.org>:

On Sat, May 15, 2021 at 4:05 AM Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, May 14, 2021 at 11:10 AM Markus Neteler <neteler@osgeo.org>
wrote:

Let me suggest to create a new release branch in the next two weeks
…

Now, the question is, also to avoid excessive cherry-picking of fixes
and changes from master (to be called 8.1 then), which of the open PR
may be merged soon?

I actually expected that you would be a “beta” release, not an RC, marked
by tagging a commit on master branch with the code as is.
This would avoid any backporting,

Yes, that’s an alternative idea.

but perhaps, it is not creating enough focus for 8.0 and having a 8.0
branch gives more freedom in what goes into the master branch.

Indeed, a full blown new release branch for G800 would open the master
branch for new (radical) changes.

@All: your opinion?

I would like to get PR #1501 (depends on #1272) into master before
branching as it is already quite large and disruptive.
It is almost ready (today I wrote first of three management
functions). I want to finish lib part before merging – management
module can be then created as a separate PR at some point later.

I’d really like to see these changes merged before the creation of grass 8 branch.

Maybe we can agree on a deadline that suits both the need to have an 8 branch for the upcoming conferences where a GRASS 8 demo is already accepted (FOSSGIS is in ~2 weeks) and the time needed to complete ongoing development at least up to a working version that can be merged.

@Maris Nartiss what do you think?

my 0.2 cents
Vero

8

On Fri, May 21, 2021 at 4:02 PM Veronica Andreo <veroandreo@gmail.com> wrote:

El jue, 20 may 2021 a las 17:21, Maris Nartiss (<maris.gis@gmail.com>) escribió:

I would like to get PR #1501 (depends on #1272) into master before
branching as it is already quite large and disruptive.
It is almost ready (today I wrote first of three management
functions). I want to finish lib part before merging – management
module can be then created as a separate PR at some point later.

I'd really like to see these changes merged before the creation of grass 8 branch.

+1

Maybe we can agree on a deadline that suits both the need to have an 8 branch for the upcoming
conferences where a GRASS 8 demo is already accepted (FOSSGIS is in ~2 weeks) and the time

(the time shrinked to days, meanwhile...)

needed to complete ongoing development at least up to a working version that can be merged.

@Maris Nartiss what do you think?

For easier testing, I have prepared a GRASS GIS 8.0.0alpha PR:
https://github.com/OSGeo/grass/pull/1597

Do not merge, but try it out locally.

Markus

9

Hi devs,

After a lot of editing and discussions in the following PR I meanwhile
also believe that it is becoming the preparation of the master branch
for G8:

"GRASS GIS 8.0 changes"
https://github.com/OSGeo/grass/pull/1597

That means:
- merge this PR into the master branch (it is not perfect, but let's
move on and create separate PR(s) for the Windows related issues)
- branch off a "8.0.0alpha" branch, just as a "throw away/ignore later" branch
- create at a later stage the official "release_branch_8_0" after
having gained some experience with the "throw away" 8.0.0alpha branch.

If there are no objections I'd merge PR 1597 in the next days.
Note: the changes include (except for Windows) the simplification of
the startup script name (grass79/grass80 --> grass).

Markus

10

Le 29 mai 2021 08:58:59 GMT+00:00, Markus Neteler <neteler@osgeo.org> a écrit :

If there are no objections I'd merge PR 1597 in the next days.

+1

I think at this stage it should just happen, especially if it's a throw-away branch.

Moritz

11

+1 from my side too

Time to move forward!

El sáb., 29 may. 2021 08:37, Moritz Lennert <mlennert@club.worldonline.be> escribió:

Le 29 mai 2021 08:58:59 GMT+00:00, Markus Neteler <neteler@osgeo.org> a écrit :

If there are no objections I’d merge PR 1597 in the next days.

+1

I think at this stage it should just happen, especially if it’s a throw-away branch.

Moritz

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

12

Hi devs,

First step done:
GRASS GIS 8.0 changes in master
(https://github.com/OSGeo/grass/pull/1597) are merged!

Next step: test compilation and soonish create a "throw-away"
8.0.0alpha branch for testing.

cheers,
Markus

13

On Mon, May 31, 2021 at 9:13 PM Markus Neteler <neteler@osgeo.org> wrote:

Hi devs,

First step done:
GRASS GIS 8.0 changes in master
(https://github.com/OSGeo/grass/pull/1597) are merged!

One problem to address soon is the absence of "grass8" in the Addons
repo, leading to errors in the CI and all related docker builds:

(log example)
Fetching <r.in.pdal> from GRASS GIS Addons repository (be patient)...
  E170000: URL 'https://github.com/OSGeo/grass-addons/trunk/grass8/raster/r.in.pdal’
doesn't exist

This requires to decide on

Restructure repository for version 8
https://github.com/OSGeo/grass-addons/issues/528

... unless we modify g.extension for now to continue to read from
"grass-addons/grass7/"...

Opinions?

Markus

14

On Mon, May 31, 2021 at 4:10 PM Markus Neteler <neteler@osgeo.org> wrote:

… unless we modify g.extension for now to continue to read from
“grass-addons/grass7/”…

Opinions?

+1 for “grass-addons/grass7/”. Confusing for those who see the URL, but good enough for now.

I started the transition for addons, but there are things to be decided. See:

https://github.com/OSGeo/grass-addons/pull/535

15

Hi all,

The new 8.0.0alpha preview branch is ready:

https://github.com/OSGeo/grass/tree/previewbranch_8_0

Best,
Markus

16

The word “branch” in “previewbranch_8_0” seems superfluous to me as it does in releasebranch_7_8 plus it is two words together without a separator. Would v8 be a good time to change that practice?

Advantages of just release_8_0:

A1) No ‘branch == releasebranch_7_8’ or ‘switch to the releasebranch_7_8 branch’ statements.

A2) Master branch is also only a branch and does not have the word branch in it.

A3) Both QGIS and GDAL use only “release”, not “branch”, in the name of their release branches.

Disadvantages of just release_8_0:

D1) In contexts where you use Git to get a specific branch or tag, you don’t see from the command that it is indeed a branch (in git --branch release_8_0, release_8_0 could, in theory, be a tag). However, you are likely to correctly guess it is a branch, not a tag, since tags for release are most often mostly the numbers only, i.e., in format v8.0 or, as in our case, 8.0.

D2) Scripts constructing the branch name from the version name will break, however it seems like a better practice to me in this case to parameterize the whole branch name and there needs to be likely other changes for v8 in these scripts anyway.

Vaclav

On Sun, Jun 6, 2021 at 2:41 AM Markus Neteler <neteler@osgeo.org> wrote:

Hi all,

The new 8.0.0alpha preview branch is ready:

https://github.com/OSGeo/grass/tree/previewbranch_8_0

Best,
Markus

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

17

Hello devs,

As you all know, grass birthday is approaching… July 29th is just around the corner. I’d love to celebrate GRASS’ bday with a new release, with a big release :wink:

Do you think that is doable? How much is missing for GRASS 8 release?

The next important date is FOSS4G 2021 on September 27th - October 2nd, where we have proposed GRASS 8 talks and workshops. If we can’t make it for GRASS GIS’ birthday, do you think it’s feasible to release before FOSS4G, say August for example?

I think it’s really important to agree on a date so we can all manage our reduced time and focus our efforts towards that aim.

What do you say?

Best,

Vero

El lun, 7 jun 2021 a las 3:34, Vaclav Petras (<wenzeslaus@gmail.com>) escribió:

The word “branch” in “previewbranch_8_0” seems superfluous to me as it does in releasebranch_7_8 plus it is two words together without a separator. Would v8 be a good time to change that practice?

Advantages of just release_8_0:

A1) No ‘branch == releasebranch_7_8’ or ‘switch to the releasebranch_7_8 branch’ statements.

A2) Master branch is also only a branch and does not have the word branch in it.

A3) Both QGIS and GDAL use only “release”, not “branch”, in the name of their release branches.

Disadvantages of just release_8_0:

D1) In contexts where you use Git to get a specific branch or tag, you don’t see from the command that it is indeed a branch (in git --branch release_8_0, release_8_0 could, in theory, be a tag). However, you are likely to correctly guess it is a branch, not a tag, since tags for release are most often mostly the numbers only, i.e., in format v8.0 or, as in our case, 8.0.

D2) Scripts constructing the branch name from the version name will break, however it seems like a better practice to me in this case to parameterize the whole branch name and there needs to be likely other changes for v8 in these scripts anyway.

Vaclav

On Sun, Jun 6, 2021 at 2:41 AM Markus Neteler <neteler@osgeo.org> wrote:

Hi all,

The new 8.0.0alpha preview branch is ready:

https://github.com/OSGeo/grass/tree/previewbranch_8_0

Best,
Markus

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

18

Hello Veronica,
thanks for pushing this forward.

Looking from a "it is ready when it is ready" perspective – what we
are missing from functionality to call 8.0 ready? (I mean only things
that are expected to be ready in less than a month)

From my side:

Band references and integration with signature files are ready to be
merged (please review!), missing functionality can wait for 8.2.
https://github.com/OSGeo/grass/pull/1272
https://github.com/OSGeo/grass/pull/1501

I'll try to work on r.in.pdal this Friday (I need to do some LiDAR
work myself). It is almost merge ready (as long as we add extra
functionality in 8.2)
https://github.com/OSGeo/grass/pull/1200

Then from my side I'd call 8.0 ready.
Māris.

2021-06-08 17:09 GMT+03:00, Veronica Andreo <veroandreo@gmail.com>:

Hello devs,

As you all know, grass birthday is approaching... July 29th is just around
the corner. I'd love to celebrate GRASS' bday with a new release, with a
big release :wink:
Do you think that is doable? How much is missing for GRASS 8 release?

The next important date is FOSS4G 2021 on September 27th - October 2nd,
where we have proposed GRASS 8 talks and workshops. If we can't make it for
GRASS GIS' birthday, do you think it's feasible to release before FOSS4G,
say August for example?

I think it's really important to agree on a date so we can all manage our
reduced time and focus our efforts towards that aim.
What do you say?

Best,
Vero

19

On Tue, 8 Jun 2021 at 16:10, Veronica Andreo <veroandreo@gmail.com> wrote:

Hello devs,

Hi,

As you all know, grass birthday is approaching... July 29th is just around the corner. I'd love to celebrate GRASS' bday with a new release, with a big release :wink:
Do you think that is doable? How much is missing for GRASS 8 release?

I would like to improve t.remove as reported
https://trac.osgeo.org/grass/ticket/3362#comment:1
I try to work on it next week

Best,
Vero

--
ciao
Luca

www.lucadelu.org

20

Ciao Luca,

El vie, 11 jun 2021 a las 12:40, Luca Delucchi (<lucadeluge@gmail.com>) escribió:

On Tue, 8 Jun 2021 at 16:10, Veronica Andreo <veroandreo@gmail.com> wrote:

Hello devs,

Hi,

As you all know, grass birthday is approaching… July 29th is just around the corner. I’d love to celebrate GRASS’ bday with a new release, with a big release :wink:
Do you think that is doable? How much is missing for GRASS 8 release?

I would like to improve t.remove as reported
https://trac.osgeo.org/grass/ticket/3362#comment:1
I try to work on it next week

This is great news! It’d be great to have t.remove flags behaviour changed/fixed in grass 8.

Shall we move the ticket in trac to an issue in github so we give it more visibility? If yes, I can do that.

cheers,
Vero