Branching strategy for spec development

[TomAugspurger]

Now that we have a release we should figure out a branching strategy going forward. I think the primary thing to consider is what version of the spec should a person visiting https://github.com/opengeospatial/geoparquet? The "currently released version, or the in-development version?

My thoughts: we keep things as is for now (just a single main branch that we develop against), at least until we hit 1.0. I think there's a bit more value in people seeing what's coming soon.

After 1.0, I could see making a dev branch. But IMO it's not worth branching until we have a change that's going to require a 1.x (or 2.0), otherwise we'll have to backport / cherry pick typo fixes and clarifications.

[jorisvandenbossche]

My thoughts: we keep things as is for now (just a single main branch that we develop against), at least until we hit 1.0. I think there's a bit more value in people seeing what's coming soon.

+1

[cholmes]

I'll reply to the overall idea thread here, but before I forget I just wanted to mention I turned on branch protection on main, requiring at least 1 review for any merge. After 0.2 we might want to up that to two reviewers, so we're sure we have good eyes on everything.

[Jesus89]

There is a little "problem" of inconsistency using only main branch: new changes are associated with the previous release until we cut a release. A developer entering the repo may think that current changes are associated with the version but this is not true, so we are generating invalid intermediate parquet files. Using a main/dev branch system solves the problem:

• main contains always the stable version
• dev contains the changes for the next version (we may even use A.B.C-dev0 versions for the intermediate changes)

Cutting a release will be a matter of creating a PR release/A.B.C from dev to main. We need to choose the default branch, but apart from that, I would include both in the README to guide the user.

I'm not against using this before 1.X, but making dev as the default branch, and then after 1.X change to main as the default branch.

[cholmes]

I'm +1 on this. That's what stac-spec has done. The biggest annoyance on it is that to have 'main' be the version that shows up when people come to the repo the first time it has to be the default. But then when people make PR's it automatically makes them against 'main', not 'dev'. In stac we had a little PR template with a checkbox that would remind them to make it against dev, so it was a minor annoyance.

[cholmes]

The other option is to have a build step on release that publishes the specification, and then the top of the repo reader refers to that as what people should read.