search

dbuenzli / topkg

The transitory OCaml software packager
http://erratique.ch/software/topkg
ISC License
69 stars 25 forks source link

Stop dropping the `v` prefix #122

Closed ghost closed 6 years ago

ghost commented 6 years ago

Can topkg stop dropping the v prefix of version numbers? Because it drops it, it's not possible to use topkg on packages that need to keep it. All Jane Street packages need to keep the v prefix, so we can't use topkg with them.

dbuenzli commented 6 years ago

Where exactly ? You have both %%VERSION%% and %%VERSION_NUM%% available for the watermarking process.

ghost commented 6 years ago

But can we make topkg distrib and topkg opam use the full version number? For instance, I'm trying to do a release of janestreet/spawn, and topkg distrib creates _build/spawn-1.0.0 and topkg opam pkg creates _build/spawm.1.0.0.

dbuenzli commented 6 years ago

Ah these ones. I'll see if I can add some kind of option here to inhibit the v removal. Meanwhile doesn't it work if you specifiy the version manually via --dist-version on these invocations ?

ghost commented 6 years ago

No, it doesn't seem to. I can do --dist-version vv1.0.0, but then the double v ends up in the tag and on github.

dbuenzli commented 6 years ago

By the way is there any particular reason why you decided to introduce that v in js's opam package ?

Whenever I need to constrain packages it's easier if everyone follows the same conventions and unless I'm mistaken historically X.Y.Z has been the dominant scheme in opam-repository.

kit-ty-kate commented 6 years ago

It seems to me that it's because they wanted to switch from an internal version schema (144.blah.blih, …) to an external one X.Y.Z with X being 0. But 0 being strictly inferior to 168blah they needed something superior in the ascii table, hence the v prefix.

dbuenzli commented 6 years ago

Makes sense. But then maybe they should have simply bulk changed these pre-existing packages versions and corresponding constraints with ~ (which unless I'm mistaken would have solved the problem, see here).

That way everyone, except for a few outliers, is left with specifying X.Y.Z. From and end user perspective it's a bit annoying to have to juggle with v vs non v, most packages, including ocaml do not have that v. And if you forget it for Js packages you are completely wrong, IIRC there was recently an instance of someone doing this in an opam-repository request.

ghost commented 6 years ago

That's what I wanted to do but I was told that changing the versions of released packages was not allowed

dbuenzli commented 6 years ago

I wonder if this couldn't be fit in the opam v1->v2 rewrites ?

ghost commented 6 years ago

Basically @avsm told me that the problem was with opam files in project repositories. These can't be bulked changed

hannesm commented 6 years ago

there's at least prior art in re-version published packages at https://github.com/ocaml/opam-repository/pull/11191 -- yes, it is a pain since you need to push the changes to all reverse dependencies. I believe it is worth it since at least I always misparse foo.v1.2.3 and put the v somewhere else.

ghost commented 6 years ago

I believe it would be a lot harder for JS packages thought. There are a lot of them and most of them have existed for a long time. Some are in debian for instance, which might cause additional issues for some users.

It'd be nice to be able to drop the v prefix but I wonder if that's a realistic project.

ghost commented 6 years ago

/cc @trefis

dbuenzli commented 6 years ago

I guess jane street packages are going to use https://github.com/samoht/dune-release so I'm closing this and let @samoht handle this in dune-release.

FWIW I still think it is a usability issue for the eco-system that Janestreet uses the v scheme in the opam repository, maybe something should be considered for the opam2 opam-repository.