On Sun, 2007-10-21 at 23:42 +0200, Udo Stenzel wrote:
Duncan Coutts wrote:
You can hack the .cabal file further to make it work in your situation,
but I don't suggest that's a great long term solution. If you wanted to
hack it you'd change it to just:
build-depends: base, bytestring =
(moving to haskell-cafe)
On Sun, 2007-10-21 at 14:55 +0200, Udo Stenzel wrote:
Duncan Coutts wrote:
New tarball releases of Cabal-1.2.1, bytestring-0.9, binary-0.4.1, tar
and others (zlib, bzlib, iconv) will appear on hackage in the next few
days.
I just tried one of them, iconv. First
Daniel McAllansmith [EMAIL PROTECTED] writes:
3. Otherwise, major.minor MUST remain the same (other version components MAY
change).
Is it an option to say SHOULD rather than MUST here? There are
other reasons for a version bump than breaking compatibility.
-k
--
If I haven't seen further,
On Thursday 18 October 2007 21:15, you wrote:
Daniel McAllansmith [EMAIL PROTECTED] writes:
3. Otherwise, major.minor MUST remain the same (other version components
MAY change).
Is it an option to say SHOULD rather than MUST here?
Of course, SHOULD is an option just like MAY is. But both
Daniel McAllansmith [EMAIL PROTECTED] writes:
There are other reasons for a version bump than breaking compatibility.
Technical reasons?
Well - say I refactor everything, and use algorithms with different
run-time complexities, and possibly introduce different bugs than the
ones the
Neil Mitchell wrote:
Hi
I agree. = 1.0 isn't viable in the long term. Rather, a specific list,
or bounded range of tested versions seems likely to be more robust.
In general, if it compiles and type checks, it will work. It is rare
that an interface stays sufficiently similar that the thing
Hi
In general, if it compiles and type checks, it will work. It is rare
that an interface stays sufficiently similar that the thing compiles,
but then crashes at runtime. Given that, shouldn't the tested versions
be something a machine figures out - rather than something each
library
I've written down the proposed policy for versioning here:
http://haskell.org/haskellwiki/Package_versioning_policy
It turned out there was a previous page written by Bulat that contained
essentially this policy, but it wasn't linked from anywhere which explains
why it was overlooked. I
On Wed, Oct 17, 2007 at 12:54:12PM +0100, Simon Marlow wrote:
I've written down the proposed policy for versioning here:
http://haskell.org/haskellwiki/Package_versioning_policy
This says:
If [...] instances were added or removed, then the new A.B must be
greater than the previous
On Wed, Oct 17, 2007 at 12:54:12PM +0100, Simon Marlow wrote:
I've written down the proposed policy for versioning here:
http://haskell.org/haskellwiki/Package_versioning_policy
It turned out there was a previous page written by Bulat that contained
essentially this policy, but it wasn't
On Thursday 18 October 2007 00:54, Simon Marlow wrote:
I've written down the proposed policy for versioning here:
http://haskell.org/haskellwiki/Package_versioning_policy
Is there technical reason for the major version number to consist of 2
components? Why not 3, 17 or (my preference)
Simon Marlow wrote:
Ultimately when things settle down
it might make sense to do this kind of thing, but right now I think an
easier approach is to just fix packages when dependencies change, and to
identify sets of mutually-compatible packages (we've talked about doing
this on Hackage
Don Stewart wrote:
stefanor:
On Mon, Oct 15, 2007 at 10:57:48PM +0100, Claus Reinke wrote:
so i wonder why everyone else claims to be happy with the status quo?
We aren't happy with the status quo. Rather, we know that no matter how
much we do, the situation will never improve, so most of us
Daniel McAllansmith [EMAIL PROTECTED] writes:
I think what you're asking for is more than that: you want us to provide
base-1.0, base-2.0 and base-3.0 at the same time, so that old packages
continue to work without needing to be updated.
Yes.
That is possible, but much more work for the
Udo Stenzel wrote:
Simon Marlow wrote:
So a package that depends on 'base' (with no upper version bound) *might*
be broken in GHC 6.8.1, depending on which modules from base it actually
uses. Let's look at the other options:
- if we rename base, the package will *definitely* be broken
Claus Reinke [EMAIL PROTECTED] writes:
You need a way to specify foo 1.2 foo 2, which is a
suggestion that was tossed around here recently.
but what does such a version range say? that i haven't tested any
versions outside the range (because they didn't exist when i wrote
my package)?
Be happy: we're about 15 years ahead of the lisp guys. 'cabal install
xmonad' works, for example.
- not on windows (and since it is popular, it will seduce more
good haskellers not to bother with windows compatibility.. :-(
- from xmonad.cabal (version 0.3, from hackage):
build-depends:
- if you provide a 'base' configuration that pulls in the stuff that
used to be in base, the package will work
I don't know of a way to do that. The name of the package is baked into
the object files at compile time, so you can't use the same compiled module
in more than one package.
Several good points have been raised in this thread, and while I might not
agree with everything, I think we can all agree on the goal: things
shouldn't break so often.
So rather than keep replying to individual points, I'd like to make some
concrete proposals so we can make progress.
1.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Simon Marlow
x changes == API changed
x constant but y changes == API extended only
x and y constant == API is identical
Ordering on versions is lexicographic, given multiple
versions that satisfy a dependency
Claus Reinke wrote:
- if you provide a 'base' configuration that pulls in the stuff that
used to be in base, the package will work
I don't know of a way to do that. The name of the package is baked
into the object files at compile time, so you can't use the same
compiled module in more
On 10/16/07, Bayley, Alistair [EMAIL PROTECTED] wrote:
Just a minor point, but would mind explaining exactly what lexicographic
ordering implies? It appears to me that e.g. version 9.3 of a package
would be preferred over version 10.0. That strikes me as
counter-intuitive.
I believe the
* Simon Marlow wrote:
further sub-versions may be added after the x.y, their meaning is
package-defined. Ordering on versions is lexicographic, given multiple
versions that satisfy a dependency Cabal will pick the latest.
x.y.z should be ordered numerically, if possible.
As suggested by
Simon Marlow wrote:
Claus Reinke wrote:
- if you provide a 'base' configuration that pulls in the stuff that
used to be in base, the package will work
I don't know of a way to do that. The name of the package is baked
into the object files at compile time, so you can't use the same
Bayley, Alistair wrote:
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Simon Marlow
x changes == API changed
x constant but y changes == API extended only
x and y constant == API is identical
Ordering on versions is lexicographic, given multiple
versions that satisfy
From: Simon Marlow [mailto:[EMAIL PROTECTED]
The lexicographical ordering would make 10.0 9.3. In
general, A.B C.D
iff A C or A == C B D. When we say the latest
version we mean
greatest, implying that version numbers increase with time.
Does that help?
Sort of. It's what
Bayley, Alistair wrote:
From: Simon Marlow [mailto:[EMAIL PROTECTED]
The lexicographical ordering would make 10.0 9.3. In
general, A.B C.D
iff A C or A == C B D. When we say the latest
version we mean
greatest, implying that version numbers increase with time.
Does that help?
On Oct 16, 2007, at 4:21 , Ketil Malde wrote:
The major/minor scheme has worked nicely for .so for ages.
i'm not so sure about that. it may be better than alternatives,
but [..]
Also, it sees a lot of testing, at least in current Linux
distributions. The point is that the end-user
On Oct 16, 2007, at 9:01 , Bayley, Alistair wrote:
From: Simon Marlow [mailto:[EMAIL PROTECTED]
The lexicographical ordering would make 10.0 9.3. In
general, A.B C.D
iff A C or A == C B D. When we say the latest
version we mean
greatest, implying that version numbers increase with
1. Document the version numbering policy.
agreed. just making everybody's interpretation explicit has
already exposed subtle differences, so documenting common
ground will help.
We should have done this earlier, but we didn't. The proposed policy, for
the sake of completeness is: x.y where:
If the convention for modifying package versions of form x.y.z is:
- increment z for bugfixes/changes that don't alter the interface
- increment y for changes that consist solely of additions to the interface,
parts of the interface may be marked as deprecated
- increment x for changes that
On Tue, Oct 16, 2007 at 01:08:49PM +0100, Simon Marlow wrote:
So rather than keep replying to individual points, I'd like to make some
concrete proposals so we can make progress.
1. Document the version numbering policy.
We should have done this earlier, but we didn't. The proposed policy,
Ross Paterson wrote:
I would make API extended only a bit more precise: any module that uses
explicit import lists will not be affected by the changes. So one can
add classes, types and functions, but not instances (except where either
the class or the type is new).
okay
You probably can't
simonmarhaskell:
Several good points have been raised in this thread, and while I might not
agree with everything, I think we can all agree on the goal: things
shouldn't break so often.
So rather than keep replying to individual points, I'd like to make some
concrete proposals so we can
Hi
I agree. = 1.0 isn't viable in the long term. Rather, a specific list,
or bounded range of tested versions seems likely to be more robust.
In general, if it compiles and type checks, it will work. It is rare
that an interface stays sufficiently similar that the thing compiles,
but then
Neil Mitchell wrote:
Hi
I agree. = 1.0 isn't viable in the long term. Rather, a specific list,
or bounded range of tested versions seems likely to be more robust.
In general, if it compiles and type checks, it will work. It is rare
that an interface stays sufficiently similar that the thing
Following is a summary of my thoughts on the matter, in large part so I can
figure out what I'm thinking... apologies if it's a bit of a ramble. All
comments welcome.
Basically
- version numbering which differs from Simon's proposal
- precise dependencies, I think the same as Simon is
[would it be possible to pick a single list to discuss this on please,
so there is no danger of some people missing some subthreads if they
aren't on all the lists, or getting messages 3 times if they are?]
On Tue, Oct 16, 2007 at 01:08:49PM +0100, Simon Marlow wrote:
2. Precise dependencies.
Claus Reinke wrote:
but calling split-base base goes directly against all basic
assumptions of all packages depending on base.
The new base will have a new version number. There is no expectation of
compatibility when the major version is bumped; but we do have an informal
convention that
but calling split-base base goes directly against all basic
assumptions of all packages depending on base.
The new base will have a new version number. There is no expectation of
compatibility when the major version is bumped; but we do have an informal
convention that minor version bumps
Claus Reinke [EMAIL PROTECTED] writes:
if this is the official interpretation of cabal package version numbers,
could it please be made explicit in a prominent position in the cabal docs?
Me too. This is not a criticism nor endorsement of any particular
scheme, just a vote in favor of having
Claus Reinke wrote:
Simon Marlow wrote:
Another reason not to change the name of 'base' is that there would be
a significant cost to doing so: the name is everywhere, not just in
the source code of GHC and its tools, but wiki pages, documentation,
and so on.
but the name that is everywhere
Claus Reinke wrote:
if this is the official interpretation of cabal package version numbers,
could it please be made explicit in a prominent position in the cabal docs?
Yes - I think it would be a good idea to make that convention explicit
somewhere (I'm sure we've talked about it in the
You need a way to specify foo 1.2 foo 2, which is a
suggestion that was tossed around here recently.
but what does such a version range say? that i haven't tested any
versions outside the range (because they didn't exist when i wrote
my package)? or that i have, and know that later
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
However, I'd like to separate it from Cabal. Cabal provides mechanism not
policy, regarding version numbers.
but the examples in the cabal docs should reflect the standard
interpretation of version numbers.
of course, i have absolutely no idea how to write stable packages under
this
On Tuesday 16 October 2007 11:45, Claus Reinke wrote:
how about using a provides/expects system instead of betting on
version numbers? if a package X expects the functionality of base-1.0,
cabal would go looking not for packages that happen to share the name,
but for packages that provide
On Mon, Oct 15, 2007 at 10:57:48PM +0100, Claus Reinke wrote:
so i wonder why everyone else claims to be happy with the status quo?
We aren't happy with the status quo. Rather, we know that no matter how
much we do, the situation will never improve, so most of us have stopped
wasting out time.
stefanor:
On Mon, Oct 15, 2007 at 10:57:48PM +0100, Claus Reinke wrote:
so i wonder why everyone else claims to be happy with the status quo?
We aren't happy with the status quo. Rather, we know that no matter how
much we do, the situation will never improve, so most of us have stopped
49 matches
Mail list logo
