How does the Reason versioning process work?

[ryyppy]

When I was upgrading the bspacks processes in #2495, I realized that it's hard to understand where the current version of Reason comes from and what the most recent version is:

• git tags end with 3.0.4 (Dec 2017)
• npmjs.org/package/reason states 3.3.4 (a year ago)
• package.json states 3.5.0
• reason.json (esy) states 3.5.1
• https://opam.ocaml.org/packages/reason/ state 3.5.2

I realized that dune takes a version env variable to inject the version into the binary. Where does this version string usually come from during a build? Is this documented somewhere?

[baransu]

Thank you for opening this issue. I think is an important topic to clarify.

[thangngoc89]

Yes. This is a very confusing process with so many versions of refmt

[ddon]

Very confusing... Looks from outside that Reason was abandoned in 2017 when it was last time released :)

[jordwalke]

Sorry for the delay:

git tags end with 3.0.4 (Dec 2017)

We don't use git tags anymore however, we still keep them just in case someone still depends on them. What can we do there to avoid confusion? People have looked at the Git tags and have walked away thinking it hasn't been updated. But we can't just take down git tags.

npmjs.org/package/reason states 3.3.4 (a year ago)

That package is not actually Reason, but a compiled-to-js version of it. However, one thing we can do to clear up confusion is that we can release the next native Reason package to npm reason (and then it would match the opam reason).

The reason.json and the esy.json's version should be kept in sync, but the esy.json's version doesn't really matter because esy.json is just a development time config.

@esy-ocaml/reason is the real native Reason package that is kept in sync with opam, and its version 3.5.2 is indeed in sync with opam thanks to @anmonteiro.

So in summary:

• The reason.json inside the repo represents the real package and its version would either be matching the official public reason package, or might be one/two versions ahead of it during prerelease time.
• @esy-ocaml/reason is the real package, and it is mirrored on opam as reason and they are both up to date, and in sync with the repo's reason.json.
• npm's reason package is a seldom used compiled-to-js version of the reason parser, but we might start using it instead of @esy-ocaml/reason.

[jordwalke]

@ddon

Very confusing... Looks from outside that Reason was abandoned in 2017 when it was last time released :)

Can I ask why you were even looking at git tags? Is this common for people to look at git tags for a project that is never installed via git tags? We can either remove the git tags (possibly breaking people) or start publishing fake git tags with versions on the off chance people look at the git tags as some sort of signal about released versions?

Either way, I think we should make it clear right on the main readme where to find the latest versions. Thanks for the reminder.

[ddon]

Sure, will explain. GitHub provides very clean and nice page for every repository, which is called "Releases" and it is using git tags:

https://github.com/facebook/reason/releases

Usually you can see what's going on with the project, by visiting this page.

[jordwalke]

I see. I wish we could put some kind of message on the releases page saying "this is not the page you are looking for". I would never think to check the releases page of an npm package for example because that's not where packages are released. I guess form time to time we can just make a dummy release or something so that people don't get the wrong idea? Or we could just make it part of the workflow to push the released npm packages to releases?

[ddon]

Potentially this selected text could explain that this is no longer relevant place, but I like more your idea about from time to time make dummy release! :)

[jordwalke]

I could make a release called Releases-Are-Now-On-Npm-Or-Opam or something.

Also, I'm going to clean up the main readme to remove tons of distracting information when people are trying to find the status - also I will add some kind of Shields that point to the latest releases on npm for various packages.

[jordwalke]

You can checkout the README now. Hopefully that clarifies things a bit. We can also add badges for other packages that we release once those are automated such as rtop etc.

[jordwalke]

[Lupus]

Badge with npm release version is a great solution! I also typically look at releases tab in a github repo to check what's the latest release, that's indeed a pretty common pattern across github users. But when I see that latest release is right in front of me when I open project page, I would just be too lazy to dig for specific git tags, so that works! Yet, may be add a notice about git tags not being used for releases in "latest releases" section as some kind of footnote? Also add this url: https://opam.ocaml.org/packages/reason/ to point to opam releases as well?

[jordwalke]

I think in the next release we cut (any moment now - waiting for signoff from BuckleScript), I'll see what the workflow is like if we release to github releases too. I mean even if I just do it this one release and not the next n, at least it will be better than one from so long ago!

[Lupus]

There isn't any particular workflow, you just put a tag on corresponding commit that you build your release from. This makes it trivial to build specific release from source if someone is willing to, just checkout tag and follow instructions on building from source.

ср, 22 янв. 2020 г., 12:07 Jordan W [email protected]:

I think in the next release we cut (any moment now - waiting for signoff from BuckleScript), I'll see what the workflow is like if we release to github releases too. I mean even if I just do it this one release and not the next n, at least it will be better than one from so long ago!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/facebook/reason/issues/2497?email_source=notifications&email_token=AAAZXBDGZBOLQDVU2KVIOBLQ7AEFFA5CNFSM4JP5YCT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJSYW2I#issuecomment-577080169, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAZXBALFH2DOCX6ROSDYITQ7AEFFANCNFSM4JP5YCTQ .

[leojrfs]

Hi, @jordwalke I must admit I am also a bit confused, I was for instance adding this repo as a pin in opam for version 3.6.0, and I found out that such tag doesn't exist. Then I tried to look through the repo and nothing was very clear, I only found old and confusing versioning tags. How can one get the exact commit a release package was built from? How does your release process work? Are package builds and releases manual?