[Haskell-cafe] Fwd: Fwd: Compatibility etiquette for apps, with cabal sandboxes and `stack`

[Sven Panne]

2015-11-29 22:03 GMT+01:00 Imants Cekusins <imantc at gmail.com>:

> > In the exporting library? In the importing library?
>
> Well, in both places. Basically, similar part of namespace guarantees that
> api is the same below.
>
To make this work on the exporting side, the namespace hierarchy would need
to be structured according to API versions. This would mean constant
reshuffling of modules in the hierarchy every time you make an API change.
Furthermore, speaking from a more aesthetical point of view, names in the
hierarchy should have some sensible semantic meaning and should not be
littered with more or less random name suffixes.

> [...] This exact same version would be pulled in alongside other versions
> of the same library, used in other parts of a large app.
>
This won't work when e.g.the libraries have a C part (unless you convince
all people out there to use some kind consistent hierarchical naming scheme
for C, too).


> It may lead to code duplication and larger binaries however it would
> essentially give you a sandbox with very little effort.
>
Personally, I don't consider littering my code with version numbers as
"little effort". Stuff like this should be specified outside of the source
code IMHO.

> Well, let's say I am working on a library. Tempting as it is to release
> the first draft, I'd first use this fresh library in a few places, catch
> some bugs, fix them, and then release.
>
> Because this takes time, this library would see very few releases per year.
>
> It would be less likely to cause multiple  version conflict.
>
This contradicts the common "release early, release often" scheme of doing
things, which has *many* advantages. And the number of releases is not
relevant in itself, it's how often you change the API, which is a totally
different matter. The longer you wait with releases, the higher the chance
is that the next release has an incompatible API change, and your users
won't get bug fixes without that API change, which won't make them
especially happy.

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151130/3bd528a2/attachment.html>