Branch management for 2.0

[dgsb]

We are regularly receiving incompatible changes with the 1.x versions.
In order to be able to incorporate those changes, we should dedicate a specific branch to allow further development without breaking existing contracts (e.g., 2.0).

As it seems that mostly everyone uses master as is as 1.x compatible version, we are stuck with master being used for the v1. wdyt ?

[sirupsen]

Please keep master fully backwards compatible with no exceptions. It's far too relied upon that I want to compromise the trust of the community. I am conflicted on how to proceed for the future, safely.

[dgsb]

Indeed, that was what I was talking about. As the master branch is used in most project as the next version branch, we could also to avoid any fogginess freeze the master branch and use a dedicated v1 branch and create when wanted a v2 branch.

[sirupsen]

I think that's the way to go David.

By the way, thanks for all your stewardship here

[theckman]

Agreed on wanting to keep things as stable as possible. We will want to make sure Go modules works correctly in the propsoed scenario.

A question this brings up in my mind is at what point do people expect v2.0 to be the default and master being v1.0 starts to become a problem? I've not personally run in to other repos that do this, so logrus would be totally undoing assumptions I've been able to make about packages in the Go ecosystem. Are we okay with that? Is it healthy? I'm not sure I have an answer.

Do we have a bar for ever making master v2.0? If we never plan on doing that, does a 2.0 even make sense since they will most-likely end up on v1.0 and the newer features won't be exercised as much?

Edit: By asking this I am not trying to dissuade a v2. I am hoping to understand both of your perspectives in this space.

[dgodd]

I noticed this thread after open a PR to add go module support (#817). I believe that the current thinking for go modules and v2 versions is to create a directory v2 inside the repository (rather than a branch). However given how much flux there is with go modules, I may be out of date with this statement.

[dgsb]

@dgodd from what I understand from this page https://github.com/golang/go/wiki/Modules we don't need to move code in a subdirectory when using go module. This is only need to import such path when NOT using go modules.

[dgsb]

@theckman, I think it would be ok to freeze the master branch. It would ensure no future build break for package consumer which are not relying on specific version. For package consumer which uses package versioning with dep or the future go modules, it should not have any impact as they probable rely on a specific tag.
It would only add complexity on contributor, but it can be solved with an appropriate contributing guide.
In short I'd rather have an explicit v1 branch rather than having an implicit master locked in v1.

[aarongreenlee]

Thank you @dgsb for raising this issue.

I suggest creating a new branch. Until Go Modules stabilize I hesitate to adopt it within the master branch.

An alternate suggestion: Create a new organization and repository and establish a completely clean start. I anticipate pushback for this suggestion. However, if such a dramatic action was combined with a campaign to encourage greater community contributions and governance it might be received well by the community.

Respectfully,

-A

[dgsb]

@aarongreenlee module definition has already been added to the mastre branch. It should not have any impact in the build process of package stored in $GOPATH/src, but can already be used by anyone else.
I think its important for a package as much used as logrus to quickly provide its modules definition in order to help other including package to also adopt/experiment with modules.

[dgsb]

@sirupsen, if you agree with the naming, I'm going to create release-v1 and release-v2 branches. I think only you has the rights to then perform the following options:

• define release-v1 as the default target branch for pull request
• potentially forbid merge request on master branch
• if you could also lock 1-0-stable as it seems to have never have been used

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.