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
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)
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
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.
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
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
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
24 matches
Mail list logo
