go-gorp/gorp

How about making a v3 branch the default branch? (suggestions for future mainenance)

Songmu opened this issue · 2 comments

Songmu commented

#411 has been merged and we are done Go Modules support in version 3.
So we may maintain version 3 as the mainline from here.

I think there are two ways to maintain the repository using version 3 as a mainline.

  • Make v3 branch the default branch on GitHub
  • Merge v3 branch to master branch

I think the former is safer. It is because changing the master branch will cause incompatible changes for projects that do not support Go Modules.

ref. "Major branch" https://github.com/golang/go/wiki/Modules

I'm familiar with Go Modules, and I use gorp aggressively at my work, so I can help with maintenance.

nelsam commented

The main development branch against which I receive PRs should not be the release branch. Release branches are for releases, and it shouldn't be up to the developer submitting a PR to decide which release a feature or bugfix goes in to. I want to receive PRs against a development branch (it's been master for ages, so no reason to change that) and merge them there, so that I can make the decision, as maintainer, about which release they go in to. Further, because go mod doesn't really support long-term use of the "latest" tag in go.mod and is aggressive about pulling down the oldest version, the development branch cannot make use of go modules.

I'm going to leave master as the primary branch and keep it free of go.mod and go.sum - but I do really want to put up a CI/CD pipeline to handle releases, to help ensure that everything gets released properly. For example, this was my first time releasing a version greater than v1.x.x - so the pathing rules caught me off-guard. Having a CI/CD to check those import paths and blow up if a release is bad would be really nice.

I'll write up some more in the contributing guidelines related to that; but I'm happy to chat with you about additional maintainership. It would be super nice to have another maintainer around to review PRs. Feel free to jump in to the gitter chat (linked from the readme) if you'd like to discuss this more actively, too.

  • 😄1
Songmu commented

Thank you for replying.

I understand the policy of making the master not to support Go Modules and keeping it main development branch.

Certainly that way, we can maintain compatibility with environments that don't use the Go Module. On top of that, running v3 branch that support Go Modules in parallel is a good way to maintain.

However, in that case, there will always be a constant difference between master and v3 branches, which I feel is a little harder to maintain. besides go.mod and go.sum, the import path will also change, as seen in the #411 pull request.

So, I think the following steps are necessary for the version 3 release. As you say, it would be good if these were done automatically by CI/CD.

  1. merge master branch into v3
  2. update go.mod and go.sum using go mod tidy
  3. check if the import path is correct, auto-detect and update
    • Update import "github.com/go-gorp/gorp" to import "github.com/go-gorp/gorp/v3".
  4. commit to v3 branch if there is an update difference in 2,3
  5. tag a new version (v3.x.x) in the HEAD of v3 branch
  6. push v3 branches and tags