Skip to content

Proposal: Add version string to communicate GopherJS's mature status, better tracking of release history. #500

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

Closed
dmitshur opened this issue Aug 21, 2016 · 2 comments

Comments

@dmitshur
Copy link
Member

dmitshur commented Aug 21, 2016

I'd like us to add a version string to the GopherJS compiler. Given how stable and mature it is by now, it should've had one a while ago. This is similar to how Go 1.0 was eventually a stable version name.

Nothing will change regarding how to download/update to latest version. master branch will still have the latest "patch" version and we will not be tagging those releases (think of each commit to master branch as a patch release). So still go get -u github.com/gopherjs/gopherjs to get latest GopherJS. No changes to that - this is purely to help communicate and track history.

The version scheme is:

x.x-y

Where x.x is the major and minor version of Go, e.g., 1.7 for today's Go 1.7. It'd be 1.6 for Go 1.6.3.

y is the version of GopherJS compiler for its version of Go. It will start at 1 and can increment for each significant change/addition/improvement/breaking change. It will correspond to new entries in the release history that note what has changed. It's a way for us to communicate externally the changes in a more summarized way than individual commits.

So, first release for Go 1.7 will be GopherJS 1.7-1. Then 1.7-2, 1.7-3, etc.

Once 1.8 comes out and GopherJS supports it, the version will bump up to 1.8-1.

1.7-1
1.7-2
1.7-3
1.8-1
1.8-2
1.9-1
...

Note that you can/should always use latest Go patch version. So it's fine to use Go 1.7.1 or 1.7.3 whenever those come out with GopherJS 1.7-1.

I've discussed this with @neelance and he was in agreement; we iterated on the versioning scheme to arrive at the above solution.

dmitshur added a commit to gopherjs/gopherjs.github.io that referenced this issue Aug 21, 2016
dmitshur added a commit that referenced this issue Aug 21, 2016
The version being referred to is the GopherJS compiler version, not
not the GopherJS build tool. That's why the canonical version string
is located in the compiler package.

The build tool's version is less important and it effectively takes on
the version of the compiler.

Helps #500.
dmitshur added a commit to gopherjs/gopherjs.github.io that referenced this issue Aug 22, 2016
@neelance
Copy link
Member

@shurcooL Close?

@dmitshur
Copy link
Member Author

dmitshur commented Sep 26, 2016

Yes, this is done now via #501 and the blog post (gopherjs/gopherjs.github.io#55).

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

No branches or pull requests

2 participants