monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conf


From: Markus Wanner
Subject: Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Date: Wed, 24 Nov 2010 13:45:45 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100913 Icedove/3.0.7

Hi,

On 11/24/2010 03:20 AM, Timothy Brownawell wrote:
> Also from IRC we have:
>    <thm_> the whole release numbering discussion is not meaningful wrt
>    rpm, as Fedora for example has its own rules, forbidding
>    non-numerics in the version part of an rpm.

Really? There are so many open source projects with non-numeric versions
that I distrust this statement. The first Google hit I get seems to
indicate that non-numeric versions are perfectly supported in Fedora as
well, see [1].

> So what's left is either even/odd to indicate release/dev, or .90/.99 to
> indicate dev.

Version numbers definitely are not floating point numbers. All cited
systems so far (deb, rpm and FreeBSD) do that correctly (meaning 0.10 is
considered newer than 0.9 and 0.100 is newer than 0.99). Please don't
repeat that mistake. (After all, who's going to trust a revision control
system that doesn't even get its own versioning correct?)

> Option 1
>    1.0 or 1.0.0, 1.0.1, 1.0.2 <- release
>    1.1                        <- dev
>    ???                        <- RC
>    1.2, 1.2.1, ...            <- release

Due to the above, I don't think we need an obscure even/odd encoding.
Other than that, I'm always in favor of giving the version number a
meaning (other than wanna-be marketing). Mostly that's about
compatibility. And people are always wondering whether or not their 1.0
is compatible to 1.1 or if they can upgrade to the upcoming 2.0 without
troubles, etc... They shouldn't have to.

For monotone, we had netsync flag days, which represent full
incompatibilities (can't speak to each other). Then we also had database
migrations, where a one-way upgarde is possible, but not backwards. So
we could encode that in the version by using MAJOR.MINOR.REVISION, where
a netsync flag day increments the major version number and a required db
migration increments the minor version number.

That way, the version number would get an actual meaning. And you could
reason about compatibility by just looking at the version number.

Regards

Markus Wanner


[1]: Fedora Project, Non-Numeric Version in Release:
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Non-Numeric_Version_in_Release



reply via email to

[Prev in Thread] Current Thread [Next in Thread]