> Do you know of any tool that rely on this?

OASIS it the most notable [1].

> ​The '.syntax' names are gone. I thought about keeping them as aliases,
but eventually they'll go away and this split already breaks opam
dependencies, so it's simpler to just do the full upgrade right now.

Usually, when you release something, you shouldn't change it. The releasing
is a process of fixing things in time. Changing a name of library is the
same as changing the library.

And consider the following example, suppose a released project.0.3 uses one
of the removed syntax packages. Ok, you will fix the opam file, and a
correct set of dependencies will be installed after an update,
but the package build system will still contain hardcoded old names (in
_oasis, Makefile, etc). So what should a package maintainer do? I see two
options.

1. Delete `project.0.3` from the repository and add new `project.0.3-???`
with a fixed build system
2. Retrospectively modify `project.0.3` build system and upload a new
tarball without changing a library.

The second option will break an expected assumption, that library
`project.0.3` should always be the same in time. The first option is not an
option also.

Also, some packages, may encode library names in the code itself. For
example, bap uses this to track dependencies of dynamically loaded plugins.
Merlin has a heuristics, that
guesses requested syntax extensions based on package names.

[1]:
https://github.com/ocaml/oasis/blob/master/src/plugins/ocamlbuild/MyOCamlbuildFindlib.ml#L161

On Tue, Jan 26, 2016 at 9:50 AM, Jeremie Dimino <jdimino@janestreet.com>
wrote:

> On Tue, Jan 26, 2016 at 1:57 PM, Ivan Gotovchits <ivg@ieee.org> wrote:
>
>> I hope that the change will not modify library names retrospectively?
>> I.e., the old versions will be still available under the `.syntax` names?
>>
>
> ​The '.syntax' names are gone. I thought about keeping them as aliases,
> but eventually they'll go away and this split already breaks opam
> dependencies, so it's simpler to just do the full upgrade right now.
>
> Also, presumably some tools rely on the `.syntax` extension, maybe it is
>> better to preserve the extension, i.e., to use `pa_sexp_conv.syntax`?
>>
>
> So far we only did this for syntax extensions with a runtime part. For
> instance type_conv doesn't have a .syntax package. Do you know of any tool
> that rely on this?
>
> --
> Jeremie
>