Branching model -> Gitflow?

[emmanuelmathot]

The unique main branch used in the repositories creates sometimes confusion and discrepancies between the latest release and what is on the main, especially when consulting the README. For instance in the file extension, until version 2.1.0 is released, version 2.0.0 is still declared in the main branch but already contains changes that will be included in the 2.1.0. A possible solution would be to use gitflow branching model: https://www.gitkraken.com/learn/git/git-flow that not only keeps main branch with production-ready code that is released but allow to create different branch types:

• Develop for finished work not released
• Feature for additions and changes WIP
• Release for preparing a release
• Hotfix for bug fixing

@cholmes @m-mohr @matthewhanson @lossyrob @jbants I propose it here in the extensions but this is also valid for the main STAC spec repo. Let me know.

[cuttlefish]

Is maintaining concurrent versions an expected use-case? (eg. a 2.0.x and 2.1.x branches receiving updates while 3.0.0 is being released) Git Flow works very well for that, but I’ve found it to have a lot of overhead in other scenarios. The extensions I’ve looked at seem to be just a continuous series of releases, not a branching stream of releases. Would switching to main as “current release” with a develop branch be sufficient? Another alternative is to set the version on main to be "n+1 alpha” immediately after the release of a version.

[m-mohr]

I think the main / develop behavior would work best as it's easier for new contributors to understand. Git Flow seems too "heavyweight" for this kind of work we are doing here.

Having that said, now with extensions in their own repos and with a variety of maintainers, we can't really enforce anything here. It's up to the maintainers to decide for a workflow. We could probably just encourage...

[emmanuelmathot]

It is not the first time I hear the argument about the overhead of gitflow branching model but I still do not see the point. What is heavy? In addition branch classfication easily helps identifying addition and changes from bug fixes or releases. Those are actions we perform in the STAC spec repos. Moreover, most of the git client have now the routines for gitflow included. Anyway, each maintainer is free to apply the branching model he wants but I think we need a way to enforce at least consistency between the main branch and the latest release.

[m-mohr]

The overhead I'm thinking about is more the learning curve required by new users. Just asking them to PR against dev was already sometimes a burden for some, but worked out. Asking "newbies" for using gitflow seems to be too complicated, some still use the GitHub Web UI or CLI directly, no "fancy" other clients involved. We are not always speaking with devs here. IMHO dev / master as in stac-spec is the approach to go.

[m-mohr]

I think the approach that recently was adopted by most extensions and also the API spec (and soon also the core Spec?!) is that we default to "main" being for development (+ branches for PRs) and then the specs get deployed somewhere.

[m-mohr]

@pieschker I think we can give this a quick/last look in the next PSC meeting and then probably close it. I tried to move this issue to a new column, but obviously, Zenhub doesn't work on my university computer.

[m-mohr]

PSC meeting 2022-12-12: We'll just have a main branch for all repos and make sure to have releases rendered explicitly, e.g. have the stac-spec rendered on GH Pages for 1.0.0 now and keep main for development work. Git Flow seems to complicated to enforce.