Master branch doesn't follow releases

Question

Master branch doesn't follow releases

c4s4 opened this issue 5 years ago · 14 comments

Code on master branch is not the same than the one of the latest v0.1.2 release. May I suggest that master branch follow latest releases?

Answer 1 · 2019-12-01T19:20:21.000Z

I think it is fine to have the master behind the release but it is up to @mattn

Answer 2 · 2019-12-01T19:23:57.000Z

Except that when you perform a good old go get github.com/mattn/anko you get an old version.

Answer 3 · 2019-12-01T19:25:38.000Z

Did you try go get -u github.com/mattn/anko

Answer 4 · 2019-12-02T15:11:18.000Z

You get the same branch, -u option doesn't solve the issue.

Answer 5 · 2019-12-02T16:36:47.000Z

Could you explain exactly what you are expecting versus what you are getting?

Answer 6 · 2019-12-02T17:31:14.000Z

When you perform a go get github.com/foo/bar you expect to get latest stable release. This is how you used to get dependencies at the beginning of Go, and I guess that many people, including me, are still getting their dependencies this way.
When I do that on Anko project, I get master branch which is not in the same state than latest release which is tagged v0.1.2. I seems to be behind this release.
Thus I suggest that you should merge v0.1.2 on master branch, so that this branch reflects latest stable release of the project.

Answer 7 · 2019-12-02T18:40:14.000Z

Not all repos are done the same way. Matt does this repo so far like the following:
The master branch has the latest code. Can see the note about this on the readme. When the master branch gets updated sometimes a new release/tag is made. Once that release/tag is made it is never updated.

I think you are asking for release/tag to be updated? If so, can see what Matt says but in my option don't think that is a good idea. Generally speaking once a release/tag is made it is never changed.

I know that some systems support pulling release/tag with wildcards. So for example can say pull 0.1.x, so it pulls the latest release/tag of 0.1.x which right now would be 0.1.2. If a new release/tag of 0.1.3 was created, that release/tag would be pulled. I think Go 1.13 has some support for release/tags but not aware of the details or if it can support wildcards.

Answer 8 · 2019-12-04T00:43:31.000Z

@c4s4 Does that make sense?

Answer 9 · 2019-12-12T00:48:30.000Z

@c4s4 So are we good?

Answer 10 · 2019-12-18T00:44:27.000Z

@mattn Close this?

Answer 11 · 2019-12-20T14:15:46.000Z

If you work on master branch, a way to get a clean version of the code while running go get is to tag clean code with tag go1, as described on page https://dev.to/yyagi/avoiding-the-master-branch-is-used-in-go-get--4p3k. Thus I suggest that you tag latest release with go1 tag.

Answer 12 · 2019-12-20T16:48:54.000Z

Have you looked at Module Queries yet?
https://golang.org/cmd/go/#hdr-Module_queries

Answer 13 · 2019-12-23T11:35:48.000Z

This is not the point here. I read in documentation:

Building:

    go get github.com/mattn/anko
    go install github.com/mattn/anko

If users follow documentation, they get random development version. Is that what users want? I guess not. I think they want latest stable release.

Answer 14 · 2019-12-29T18:54:44.000Z

Not sure which way you are using the word stable. In terms of bugs or usablity, the master branch should be as stable as any release. Even releases can have bugs in them. New releases are not done because they are more stable in terms of bugs.

If you mean stable as in api changes, the api can change between one release and another. Or from a release and master branch. New releases are done because of api changes.

So I am still not clear what problem you are wanting solved.