ChrisK wrote:
I disagree with Simon Marlow here. In practice I think Claus' definition of
compatible is good enough:
I don't think you're disagreeing with me :-) In fact, you agreed that
extending an API can break a client:
One can write such a module. But that is only a problem if the
the idea was for the cabal file to specify a single provided api,
but to register that as sufficient for a list of dependency numbers.
so the package would implement the latest api, but could be used
by clients expecting either the old or the new api.
I don't see how that could work. If the
Claus Reinke wrote:
a few examples, of the top of my head:
- consider the base split in reverse: if functionality is only repackaged,
the merged base would also provide for the previously separate
sub-package apis (that suggests a separate 'provides:' field,
though, as merely
I disagree with Simon Marlow here. In practice I think Claus' definition of
compatible is good enough:
Simon Marlow wrote:
Claus Reinke wrote:
- consider adding a new monad transformer to a monad transformer
library, or a new regex variant to a regex library - surely the new
package
