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

Plan for go-log releases #68

Closed
lanzafame opened this issue Nov 1, 2019 · 7 comments
Closed

Plan for go-log releases #68

lanzafame opened this issue Nov 1, 2019 · 7 comments
Assignees

Comments

@lanzafame
Copy link
Contributor

With the upcoming deprecation of the current go-log interface, I thought it best if we spell out what the releases are going to be and how they will interact with go modules and what any end-users will want to do to stay where they are or move forward.

Current release: 0.0.1

The current release 0.0.1 simply adds go modules support to go-log.

Transition release: 1.0.0

Because go modules has a special meaning assigned to versions 0.x.x and 1.x.x, any new package will import the latest version of go-log, so to prevent surprising users with broken code, I propose that we make 1.0.0 be the current master branch plus #67. This way 1.0.0 will contain both old and new APIs in full.

Only New API release: 2.0.0

To ensure that we don't break anyone's code by accident, I propose that the codebase represented by #65, will be tagged as 2.0.0. This is because go mod considers this to be a separate package entirely from the 0.x.x->1.x.x package. 2.0.0 will only contain the new API which has the zap logging package as it's backend.

Step by step plan

  1. Merge add IPFS_* env vars back for transitionary release of go-log #67 to restore full backwards compatibility but keep future compatibility
  2. Tag 1.0.0 release
  3. Merge remove deprecated code and update README #65, removing all deprecated code
  4. Tag 2.0.0 release
@lanzafame
Copy link
Contributor Author

//cc @Stebalien @Kubuxu @raulk @frrist @vyzo

@lanzafame
Copy link
Contributor Author

Note: once 1.0.0 has been tagged, I will go through and update all the PRs I have open against libp2p and ipfs to use 1.0.0 go-log package.

@Stebalien
Copy link
Member

IMO, switching to 2.0.0 at this point is worse than just leaving a deprecated Warningf (possibly indefinitely). If we switch to 2.0.0, and don't want two loggers active at the same time, we'll need to keep a shim that adds Warningf back in the 1.0.0 version. That's way more trouble than it's worth.

If we're worried about calls to the deprecated Warningf function breaking CI, that's kind of the point.

@lanzafame
Copy link
Contributor Author

At this point, all instances of Warningf have been removed, across ipfs and libp2p. This process will have no effect on those two projects, other than me updating those PRs to change the go-log dependency to a tagged release. This process is for any downstream users of go-log, so they don't get auto-updated to that latest tag and find they have broken code.

@frrist
Copy link
Member

frrist commented Nov 20, 2019

@Stebalien @lanzafame what if we did a patch version bump? #67 would be 0.0.2 and #65 would be 0.0.3?

@Stebalien
Copy link
Member

That would work but, honestly, it doesn't really matter any which way. @lanzafame has convinced me that a major version bump isn't really an issue and we should be less scared of them.

@lanzafame
Copy link
Contributor Author

Plan has been implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants