Restructure repository for version 8

[wenzeslaus]

The grass-addons repository will be restructured to accommodate better a new major version of GRASS GIS. To put it simply, we don't want to add another subdirectory grass8 next to existing grass6 and grass7 directories and we are taking the opportunity of upcoming release of 8.0.0 to change to a better system, more fitting with having multiple past major versions and with using Git.

This topic was discussed previously and most recently at PSC meeting on May 11. Please provide feedback for the plan below and/or volunteer. Help with identification of what will break is especially welcome. Complete reworkings of the plan are possible.

Goals:

• Use branches for different and old versions as in the core repository, not subdirectories.
• Make the new structure future-proof, i.e., such that when v9 comes, it is clear what to do.
• Keep addons working for the latest release (whatever is the latest patch version) of v7.

This issue is to track the main transition, but individual issue can be created to track specific issues both here and in the core grass repository as needed. We hope that more people will help with this. So far @landam plans to update the addon compilation for Windows and @wenzeslaus plans to do the changes in the branching and GitHub Actions updates in the grass-addons repository. Please add yourself and/or TODO items here as needed by editing this issue description.

TODOs:

• Create branch (from master branch) for contents of grass6 directory (named grass6, grass_v6?). Restructure the contents as needed. Delete the directory on master branch. @wenzeslaus #535
• Apply Black to the grass7 code in master branch so that it is similar in v7 and v8 to make backporting easier. #537
• Create new branch (from master branch) for v7 (named grass8? main?). @wenzeslaus
• Move contents of grass7 directory to the top level or rename it to src in the branch for (new) v7 and v8. @wenzeslaus #571
• Make changes in the compilation and checks of addons in GitHub Actions. @wenzeslaus #571
• Write to grass-dev about the change. @wenzeslaus (see grass-dev)
• Make grass8 the default branch, update to the current master branch, make the master branch read-only. @wenzeslaus
• Inform contributors in PRs.
• Update PRs if needed (for stale but desired PRs).
• Update the contributing instructions for v7. @wenzeslaus
• Update the contributing instructions for v8. @wenzeslaus #636
• Create branch (from grass7 branch) for v8 (named grass8). @wenzeslaus (3rd Dec 2021)
• Make changes in the compilation of addons on Windows. @landam @hellik
• Make changes in the compilation of addons for Linux logs. @neteler
• Make changes in the compilation of addons for manual pages. @neteler see #613 / #615 (?)
• Make changes in g.extension. @ninsbl OSGeo/grass#1700
• Make changes in documentation.

Anticipated issues:

• PRs need to be opened against other branch than master branch which makes making PRs little more difficult. Untested, but the default should make it right in most cases.
• If master branch is kept as legacy, cloning may be little confusing. Setting the default branch should make things right, but may not avoid the confusion completely.

Other comments:

• We are creating a branch for contents of the grass7 directory (named grass7). The master branch will remain in place, but new v7 releases will use the new branch and updates (and later backports) will go to this new branch.
• The grass7 branch will be superseded by the a branch called grass8 before the 8.0.0 release (likely before branching off release branch for the 8.0 series). New development should go to the grass8 branch. Updates to the grass7 branch can be done if needed, i.e., if the addon contributor or anybody else desires the backport. The best method will likely be going through the standard branch+PR procedure and cherry-picking the change from the grass8 branch.

[lucadelu]

I like the proposal, I suggest to call branch for grass8 grass8 and not main otherwise when we will have grass9 we need to rename a branch.

Just a question do we need to modify g.extension in grass7 right? for grass6.4 it will not work anymore? (sometime I discovered someone using still that version :-( )

[wenzeslaus]

Opinions on renaming of the grass8 (grass7) subdirectory in the grass8 branch to src versus moving everything to the top level? @marisn ...

In #535, you can see src subdirectory in action.

[wenzeslaus]

Just a question do we need to modify g.extension in grass7 right? for grass6.4 it will not work anymore?

If we keep the master branch as is, the older releases should still work the same. I don't know if 6.4 can install addons at this point. It seems unlikely.

However, my understanding is that we are changing code in 7.8 to use the new structure so that it is in sync with 8 and backports are straightforward. It is not captured in the description, but I think that's what we talked about. Comments? @landam @neteler

[neteler]

Just a question do we need to modify g.extension in grass7 right? for grass6.4 it will not work anymore?

If we keep the master branch as is, the older releases should still work the same. I don't know if 6.4 can install addons at this point. It seems unlikely.

GRASS GIS 6: We may (!) modify g.extension as a service to our users. I believe it is broken anyway since the latest commit was on Jul 3, 2013, and it doesn't reflect the move to GitHub. Llow prio, though.

However, my understanding is that we are changing code in 7.8 to use the new structure so that it is in sync with 8 and backports are straightforward. It is not captured in the description, but I think that's what we talked about. Comments? @landam @neteler

Yes, please. The maintenance burden should remain low.

[ninsbl]

We should probably also switch to python3 shebang during the move to grass8 and make clear that python2 compatibility for addons can be broken /removed for G8.

[HuidaeCho]

moving everything to the top level

src looks clean, but moving everything to the top level is more consistent with the core. But still, addon doesn't separate scripts from C modules like the core. I think moving everything to the top level would be better?

[wenzeslaus]

src looks clean, but moving everything to the top level is more consistent with the core.

We were acually thinking about moving these things to src in core. See Trac wiki page by @marisn and myself.

But still, addon doesn't separate scripts from C modules like the core.

This is maybe a partially separate discussion. It is not consistent, but the reasons are organizational/practical.

I think moving everything to the top level would be better?

The top level tends to grow. Now we are not doing it consistently with core, but we are trying to do it right since we need to restructure it anyway.

[wenzeslaus]

Description updated (yet again) to include current plans and todo list including the changes related to v7.

[wenzeslaus]

The grass8 branch was created and it is now the default branch. Please, see the updated description for the previously identified missing parts.