package revisionism can break things

[toolslive]

Sometimes, a package is patched after a release, and then it's released again, with the same version.

This practice makes it hard to track dependency changes, but it also (probably) changes the checksums of the modules in the package. As a consequence, this can break the usage of this module in a dynamically loadable plugin context. It has happened quite a few times for us, and I think it's just as easy to just release a new version whenever the code changed.

As a concrete example,
the recent patching of oUnit.2.0.0 causes a

   Dynlink.Error "interface mismatch on OUnitConf"

[hannesm]

I'd be very much in favour if you add custom patches to a released package, bump its version (a lengthy discussion is #10350 (comment)). there's no harm in having foo-1.0-1 etc. around, and makes it obvious which package is actually installed. if the source checksum of a package changes while that package is released to opam-repository, there shoud as well be a version bump (at least a -n suffix, and the old version may need to be removed).

if the maintainers of opam-repository agree with this ("no patches / modification of released packages"), it should be communicated in CONTRIBUTING.md. It would make this opam repository more immutable (easier to debug issues). the downside is that upon a new version opam recompiles all reverse dependencies - but imho this is required (as @toolslive outlined above).

[hcarty]

I ran into something similar today - I tried to opam update -u which triggered a rebuild of effectively everything due to a change to ocamlfind 1.7.3 (the version I already have/had installed). The result left my switch in a broken state, with Lwt unable to build for example.

The fix was to install a fresh switch, but in this case the error message was not very helpful, saying that Lwt's configuration script could not build a basic toplevel.

[dbuenzli]

if the maintainers of opam-repository agree with this ("no patches / modification of released packages"), it should be communicated in CONTRIBUTING.md. It would make this opam repository more immutable (easier to debug issues). the downside is that upon a new version opam recompiles all reverse dependencies - but imho this is required (as @toolslive outlined above).

@hannesm To move on this issue I would suggest you prepare a PR that does communicates the rules and a scheme in CONTRIBUTING.md.

One of the problem I see is that there's no way to make sure that the new name allows to fit existing constraints on the package in other packages. This means that all the other packages constraints have to be updated and that upstream needs to be aware of this new version name (for e.g. when it opam submits). In some sense you would like a new version number vn that sorts against the old one vo as vo < vn but such that for all v : vo < v implies vn < v. But maybe I'm missing something w.r.t. how version ordering works.

[pmetzger]

MacPorts has a notion of a revision number for all packages. Packages start (naturally) at revision number 0. If you make any substantive change to a package (altering dependencies, patches, anything else), you bump the rev number. When the package gets upgraded to the next maintainer release, you put the rev number back to 0 again. For simplicity, the revision field is assumed to be 0 if it isn't listed in the Portfile, so in the usual case (in which nothing gets changed between maintainer releases), you don't have to edit anything at all.

[toolslive]

b610e6d
broke our builds.

[kit-ty-kate]

@toolslive could you please give more information ?

[domsj]

@kit-ty-kate the linked commit breaks the build for users that specify snappy.0.1.0 that use an ocaml-version >= 4.06 (with unsafe-string option enabled), so we had to adapt...