Stack may already do something like this, I don't know. Anyway, here is an idea. Currently .cabal lists version or version range. What if package info included lists of API-compatible versions of this package? Let's say one library requires v10 of packageA. Another library requires v15 of the same packageA. This is a hypothetical scenario :-P However v10, v15 are API-compatible as far as package maintainer knows. Package info specifies v10 and v15 as API-compatible too. What if it were possible to issue: cabal install packageA .. and then if v10, v15 are compatible, v15 is returned without warnings. If v10 and v15 are not compatible, cabal would warn. Basically instead of library clients needing to test multiple library versions or requiring 1 exact version, deps could be specified as 1 version (with which development took place) and cabal (with hints from package maintainers) would figure this out. It might even be possible to fine-tune it to check modules & symbols actually used by library consumer app. ?
This is exactly what the Package Versioning Policy is for. By using
semantic versioning, your .cabal file can specify that you use version
1.0.* of a given package. Any API-compatible versions of that package are
supposed to be in the 1.0 range. Versions 1.1 and above are considered API
incompatible.
On Tuesday, January 26, 2016, Imants Cekusins
Stack may already do something like this, I don't know. Anyway, here is an idea.
Currently .cabal lists version or version range.
What if package info included lists of API-compatible versions of this package?
Let's say one library requires v10 of packageA. Another library requires v15 of the same packageA. This is a hypothetical scenario :-P
However v10, v15 are API-compatible as far as package maintainer knows. Package info specifies v10 and v15 as API-compatible too.
What if it were possible to issue: cabal install packageA .. and then if v10, v15 are compatible, v15 is returned without warnings. If v10 and v15 are not compatible, cabal would warn.
Basically instead of library clients needing to test multiple library versions or requiring 1 exact version, deps could be specified as 1 version (with which development took place) and cabal (with hints from package maintainers) would figure this out.
It might even be possible to fine-tune it to check modules & symbols actually used by library consumer app.
? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org javascript:; http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-- -- Dan Burton
semantic versioning ... Any API-compatible versions of that package are supposed to be in the 1.0 range. Versions 1.1 and above are considered API incompatible.
Thank you Dan. so changes in 1/10th indicate API changes? however if package info included symbols / modules with breaking changes, a wider range of versions might become compatible. e.g. half package modules might behave just as before yet a few API methods in the other half might have changed leading to a different version and (possibly unnecessary) version clash. by making cabal smarter and better informed, compatible version range would increase. it seems
.. also (with just semantic versioning as a guide) what about new API features which do not break previous API? new version -> clash?
Thank you Dan. so changes in 1/10th indicate API changes?
Yes the first two components signify the major version.
The mysterious Backpack might be able to help with some of these things but
in general it's not enough just to look at the visible API. I might require
V10 of a library because it fixes a bug in a subtle way (such as changing
the encoding of certain characters in a URI), or changed behavior that
isn't visible in haddocks (a ToJSON instance that now produces property
names in lowercase). It can be argued that both of these should be changed
in a major update, but the PVP does not require this and neither can it
specify breaking changes to an arbitrary level of granularity. As a
maintainer I might still need to both whitelist versions I know are good
and blacklist those that are not to make sure users don't get a package
combination that doesn't work as expected.
- Adam
On Tue, Jan 26, 2016 at 6:10 PM, Imants Cekusins
.. also (with just semantic versioning as a guide) what about new API features which do not break previous API?
new version -> clash? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
As a maintainer I might still need to both whitelist versions I know are good and blacklist those that are not to make sure users don't get a package combination that doesn't work as expected.
of course, maintainer input would be essential. For simple utility libraries we could get away with file compare. However even in different versions there may be fully compatible code. If a package only uses still compatible code, why not save users a reinstall? semantic versioning as it is, is very restrictive (or misleading if versions are not upped for 'small changes').
.. as to the additional info, would it not be enough to list modules and symbols which produce different results compared to previous version? could cabal be tweaked to compare a list of (installed, required) versions (with sets of blacklisted symbols) with symbols actually used in a library, to suggest ok / reinstall?
participants (3)
-
Adam Bergmark -
Dan Burton -
Imants Cekusins