> but the name that is everywhere does not stand for what the new version
> provides! any place that is currently referring to 'base' will have to be
> inspected to check whether it will or will not work with the reduced
> base package. and any place that is known to work with the new
> base package might as well make that clear, by using a different name.
base changed its API between 2.0 and 3.0, that's all. The only difference
between what happened to the base package between 2.0 and 3.0 and other
packages is the size of the changes. In fact, base 3.0 provides about 80%
the same API as version 2.0.
so it is not just an api extension, nor an api modification with auxiliary
definitions to preserve backwards api compatibility, nor a deprecation
warning for api features that may disappear in the distant future; it is
an api shrinkage - features that used to be available from dependency
'base' no longer are. and it isn't just any package, it is 'base'!
the decision to make the difference visible in package names was made
when subpackages were created from the old base. if cabal can handle
multiple versions of base coexisting, and can guess which version was
meant when someone wrote 'base', then no renaming is necessary. but
if cabal can't handle that (yet), then renaming might be a workaround,
to avoid more trouble.
if ghc told me that "expected type 'base' doesn't match inferred type
'base'", i'd file a bug report. why do we throw out such standards
when grouping modules into packages?
Exactly what percentage change should in your opinion require changing the
name of the package rather than just changing its version number? Neither
0% nor 100% are good choices... packaging is rarely clear-cut!
then we should ask: why not?
it seems to be a standard type system problem: either we have no
subtyping, then the types/versions/apis must match precisely, however
inconvenient that might be, or we have subtyping, then we need to
define what we want it to mean that one package version may be
used instead of another. just having names and numbers and schemes
that give no guarantees that matches imply compatibility is no solution.
i don't want a package manager that tells me: "congratulations!
your package is 88.745% likely to be buildable, it provides
between 45% and 95% of the features your package spec
promises (since all promises are informal, no precise validation
is possible, but most users should be happy), provided that
our dependencies really do provide all the features we depend
on (i have no idea what those features might be). go ahead and
publish it. let others clean up the mess. oh, and remember to
come back every couple of months or so to clean up the mess
made by those providing your package's dependencies.".
of course, cabal doesn't even tell me that. it lets me publish
anything (shouldn't there be a './Setup check' to validate? or
is there?) and only gets involved when people try to build
what i published, usually months later, when anything might
happen (depending on how good my package spec was,
and on what happened to the dependencies in the meantime),
followed by someone chasing me, then me chasing someone
else, or someone giving up.
is this too bleak a view?-)
claus
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
