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, byt
(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
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 appli
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. B
Ross Paterson wrote:
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 pol
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 furthe
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)
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 wa
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
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 too
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
> > l
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
[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
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 propos
On Tue, 2007-10-16 at 14:01 +0100, 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", im
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
> 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 cr
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
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
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 po
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 inclu
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:
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
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 experie
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 he
> 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?
Sor
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 satis
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
compil
* 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
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
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 tha
> 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 dep
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. Doc
- 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.
i've
On Tuesday 16 October 2007 21:16, Simon Marlow wrote:
> > - when GHC 6.8 comes out containing base-3, will it be possible to
> > additionally install something calling base-2 with both being
> > available to packages?
>
> In theory yes - the system was designed to allow this. In practice we've
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:
"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 wrot
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
-
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 w
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 m
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 b
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 stoppe
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.
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 th
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 interpr
> 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 packa
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 v
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 pa
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
"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
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 bum
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
52 matches
Mail list logo