Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restructure repository for version 8 #528

Closed
14 of 17 tasks
wenzeslaus opened this issue May 14, 2021 · 10 comments
Closed
14 of 17 tasks

Restructure repository for version 8 #528

wenzeslaus opened this issue May 14, 2021 · 10 comments
Assignees
Labels
enhancement New feature or request

Comments

@wenzeslaus
Copy link
Member

wenzeslaus commented May 14, 2021

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:

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.
@wenzeslaus wenzeslaus added the enhancement New feature or request label May 14, 2021
@lucadelu
Copy link
Contributor

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 :-( )

neteler added a commit to OSGeo/grass that referenced this issue Jun 2, 2021
Temporary workaround of using grass7 subdir of addon-repo, see
OSGeo/grass-addons#528

* g.extension: workaround to use grass7 addon repo but redefining major version
* workaround: also set minor version
a0x8o added a commit to a0x8o/grass that referenced this issue Jun 2, 2021
Temporary workaround of using grass7 subdir of addon-repo, see
OSGeo/grass-addons#528

* g.extension: workaround to use grass7 addon repo but redefining major version
* workaround: also set minor version
a0x8o added a commit to a0x8o/grass that referenced this issue Jun 2, 2021
Temporary workaround of using grass7 subdir of addon-repo, see
OSGeo/grass-addons#528

* g.extension: workaround to use grass7 addon repo but redefining major version
* workaround: also set minor version
@wenzeslaus
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member

neteler commented Jun 18, 2021

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
Copy link
Member

ninsbl commented Jun 24, 2021

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member Author

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

@wenzeslaus
Copy link
Member Author

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

@ninsbl
Copy link
Member

ninsbl commented Sep 24, 2022

I think we can consider this done, no?

ninsbl pushed a commit to ninsbl/grass that referenced this issue Oct 26, 2022
Temporary workaround of using grass7 subdir of addon-repo, see
OSGeo/grass-addons#528

* g.extension: workaround to use grass7 addon repo but redefining major version
* workaround: also set minor version
ninsbl pushed a commit to ninsbl/grass that referenced this issue Feb 17, 2023
Temporary workaround of using grass7 subdir of addon-repo, see
OSGeo/grass-addons#528

* g.extension: workaround to use grass7 addon repo but redefining major version
* workaround: also set minor version
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

8 participants