Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
In message 4ced08f9.1040...@bluegap.ch on Wed, 24 Nov 2010 13:45:45 +0100, Markus Wanner mar...@bluegap.ch said: markus (After all, who's going to trust a revision control system markus that doesn't even get its own versioning correct?) Oh, I just have to pick on this one: revisions and versions aren't the same thing... Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
In message 4ced08f9.1040...@bluegap.ch on Wed, 24 Nov 2010 13:45:45 +0100, Markus Wanner mar...@bluegap.ch said: markus For monotone, we had netsync flag days, which represent full markus incompatibilities (can't speak to each other). Then we also had database markus migrations, where a one-way upgarde is possible, but not backwards. So markus we could encode that in the version by using MAJOR.MINOR.REVISION, where markus a netsync flag day increments the major version number and a required db markus migration increments the minor version number. 0.99 is different enough from 0.48 to deserve being the upcoming 1.0, there are enough changes even if it's compatible on a netsync level. With that, I mean to say that netsync changes shouldn't be the only criterium. Cheers, Richard ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On 11/24/2010 09:54 PM, Richard Levitte wrote: Oh, I just have to pick on this one: revisions and versions aren't the same thing... Okay, then let's talk about VCSes.. ;-) Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On 11/24/2010 09:56 PM, Richard Levitte wrote: 0.99 is different enough from 0.48 to deserve being the upcoming 1.0, Huh? I'm sorry if that's ignorant, but I didn't realize any change in 0.99, except for it being slower, but less annoying with the commit message editor than 0.48. there are enough changes even if it's compatible on a netsync level. With that, I mean to say that netsync changes shouldn't be the only criterium. I'm open to other criteria, but we feel it should be 1.0 is not something I find a compelling argument. Newly added features that are compatible (back- and forwards), no matter how important or cool they are, hardly ever have the impact that a change leading to incompatibilities has. Because such new features optionally enable something new, for users who care, while incompatibilities inevitably disable existing users, even they don't care. So, I'm not arguing that netsync changes should be the only criterium, but *compatibility*. Everything else, including marketing, importance of features, stability, usefulness, etc... is subjective and not something that should have an influence on a version number, IMNSHO. (For example, I'd currently rather use 0.47 than 0.48 or 0.99, because that version just worked better for me. It's my subjective view - and certainly doesn't help in understanding the planned move to 1.0). Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Richard Levitte rich...@levitte.org writes: In message 4cec7683.2090...@prjek.net on Tue, 23 Nov 2010 20:20:51 -0600, Timothy Brownawell tbrow...@prjek.net said: tbrownaw Option 1 tbrownaw1.0 or 1.0.0, 1.0.1, 1.0.2 - release tbrownaw1.1- dev tbrownaw???- RC tbrownaw1.2, 1.2.1, ...- release tbrownaw tbrownaw Option 2 tbrownaw1.0, 1.0.1, 1.0.2, ... - release tbrownaw1.0.90 - dev tbrownaw1.0.91, 1.0.92 - RC tbrownaw1.1, 1.1.1, 1.1.2, ... - release Shall we vote? In that case, I vote for option 2. I also vote for option 2. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Am 24.11.2010 03:20, schrieb Timothy Brownawell: Option 2 1.0, 1.0.1, 1.0.2, ... - release 1.0.90 - dev 1.0.91, 1.0.92 - RC 1.1, 1.1.1, 1.1.2, ... - release +1 Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Markus Wanner mar...@bluegap.ch: 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]. Time for a clarification of my note on IRC. The well-known-to-Fedora-packagers website you are citing says, that because of the ordering problems, a Fedora package may *not* have non-numeric parts (besides the dot, obviously) in the *version* part of an RPM name. The website therefore deals with the question where to put these non-numeric parts of a version number so many upstream projects make use of: For any Fedora RPM they have to be put in the *release* field of the RPM name, but prefixed by a number (and even two numbers in case of a pre-release, the first of them being zero.) For example, upstream uses: monotone-1.0rc1, and this is intended to be a pre-release, then the first-attempt Fedora package would have to be called monotone-1.0-0.1.rc1, the second attempt monotone-1.0-0.2.rc1, the next release candidate maybe monotone-1.0-0.3.rc2, the final 1.0 package monotone-1.0-1, and a later devel package from trunk monotone-1.0-2.20110229mtncafebabe. So in short, what this packaging guideline basically does, is forcing the maintainer to *manually* ensure proper ordering via the release field. Therefore, it is irrelevant what version scheme we (as monotone upstream) come up with, I (as Fedora monotone packager) might have to adopt it anyway to be consistent with the packaging guideline, so we don't *need* to discuss (or take into account) any particularities of RPM version number ordering here on this list. Hope that clarifies it a bit, Thomas -- Thomas Moschny thomas.mosc...@gmx.de ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
In message 4ceb4d64.9050...@prjek.net on Mon, 22 Nov 2010 23:13:08 -0600, Timothy Brownawell tbrow...@prjek.net said: tbrownaw On 11/22/2010 10:48 PM, Hendrik Boom wrote: tbrownaw On Mon, Nov 22, 2010 at 11:46:49PM -0500, Hendrik Boom wrote: tbrownaw On Mon, Nov 22, 2010 at 05:28:23PM -0600, Timothy Brownawell wrote: tbrownaw On 11/22/2010 09:43 AM, Hendrik Boom wrote: tbrownaw This if we add ~dev7 to version number 1.1, we'll get version tbrownaw 1.1~dev7, tbrownaw which will sort before version 1.1 tbrownaw tbrownaw This sounds like the numbering system we're looking for. tbrownaw tbrownaw Of course, this isn't the *entire* comparison alrorithm. There's also tbrownaw an epoch and a Debian-specific attachment to the verison number. tbrownaw Check tbrownaw the link above for further details. tbrownaw tbrownaw Yep, that would be ideal except it looks like rpm-based distros don't tbrownaw support it. tbrownaw tbrownaw Maybe we should log a bug against rpm itself. tbrownaw tbrownaw Maybe we should first find out what the actual specifications are for tbrownaw version numbers in rpm. tbrownaw tbrownaw http://rpm.org/gitweb?p=rpm.git;a=blob_plain;f=lib/rpmvercmp.c;hb=HEAD tbrownaw tbrownaw Numeric segments are newer then alpha segments, anything other than an tbrownaw alnum is a separator and is otherwise ignored. So abc123.de-~f8g has tbrownaw segments abc (alpha), 123 (numeric), de (alpha), f (alpha), tbrownaw 8 (numeric), g (alpha). I also found a perl module earlier today tbrownaw that claimed to have copied an earlier rpm version; that had alpha tbrownaw vs. numeric segments in the same position as arbitrary/undefined but tbrownaw was otherwise the same. How does the algorithm compare when one of the version has a segment empty and the other doesn't in corresponding positions? To take a current example, how does 0.99 (segments 0 and 99) compare with 0.99.1 (segments 0, 99 and 1) according to those algorithms? How would 0.99 compare with 0.99dev (segments 0, 99 and 1)? My personally interpretation would be that 0.99dev would be older than 0.99, which would be older than 0.99.1, so as value goes, the empty segment would be newer than a alpha segment but be older than a numeric segment... Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Hi, On Mon, 22 Nov 2010 07:36:30 +0100 Martin Dvorak wrote: Hi, I never was fan of the x.99.x/x.9x/etc. version numbering for betas of new major versions. I've been thinking about stable/development version numbering recently (and also in the past) and I think it's better to call such versions as 1.1-alpha5, 1.1-beta3, 2.0-rc2. This means using the target major version but appending a suffix that marks it's not the final release. What do you think? Are there any issues with this scheme for users and/or automatic tools, such as package managers in Linux? If we assume that we will release the final versions shortly after -alpha, -beta, or -rc releases, distributions should not need to care about extra suffix. They can simply package the official 1.1, 1.2.1, etc. versions. bye, Martin -- Tero Koskinen tero.koski...@iki.fi ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On 11/23/2010 03:17 AM, Richard Levitte wrote: In message4ceb4d64.9050...@prjek.net on Mon, 22 Nov 2010 23:13:08 -0600, Timothy Brownawelltbrow...@prjek.net said: tbrownaw On 11/22/2010 10:48 PM, Hendrik Boom wrote: tbrownawOn Mon, Nov 22, 2010 at 11:46:49PM -0500, Hendrik Boom wrote: tbrownawOn Mon, Nov 22, 2010 at 05:28:23PM -0600, Timothy Brownawell wrote: tbrownawOn 11/22/2010 09:43 AM, Hendrik Boom wrote: tbrownawThis if we add ~dev7 to version number 1.1, we'll get version tbrownaw1.1~dev7, tbrownawwhich will sort before version 1.1 tbrownaw tbrownawThis sounds like the numbering system we're looking for. tbrownaw tbrownawOf course, this isn't the *entire* comparison alrorithm. There's also tbrownawan epoch and a Debian-specific attachment to the verison number. tbrownawCheck tbrownawthe link above for further details. tbrownaw tbrownawYep, that would be ideal except it looks like rpm-based distros don't tbrownawsupport it. tbrownaw tbrownawMaybe we should log a bug against rpm itself. tbrownaw tbrownawMaybe we should first find out what the actual specifications are for tbrownawversion numbers in rpm. tbrownaw tbrownaw http://rpm.org/gitweb?p=rpm.git;a=blob_plain;f=lib/rpmvercmp.c;hb=HEAD tbrownaw tbrownaw Numeric segments are newer then alpha segments, anything other than an tbrownaw alnum is a separator and is otherwise ignored. So abc123.de-~f8g has tbrownaw segments abc (alpha), 123 (numeric), de (alpha), f (alpha), tbrownaw 8 (numeric), g (alpha). I also found a perl module earlier today tbrownaw that claimed to have copied an earlier rpm version; that had alpha tbrownaw vs. numeric segments in the same position as arbitrary/undefined but tbrownaw was otherwise the same. How does the algorithm compare when one of the version has a segment empty and the other doesn't in corresponding positions? To take a current example, how does 0.99 (segments 0 and 99) compare with 0.99.1 (segments 0, 99 and 1) according to those algorithms? How would 0.99 compare with 0.99dev (segments 0, 99 and 1)? My personally interpretation would be that 0.99dev would be older than 0.99, which would be older than 0.99.1, so as value goes, the empty segment would be newer than a alpha segment but be older than a numeric segment... 0.99 = 0 99 0.99dev = 0 99 dev 0.99.1= 0 99 1 0.99~dev = 0 99 dev first all have a number zero, which are equal. Next they all have a number 99 which are also equal. For the last segment we have (blank) vs string dev vs number 1. On dev vs 1, dev will be older and 1 will be newer. On (blank) vs. either... it will hit the break near the top and then at the end the whichever version still has characters left over wins, so (blank) will sort first. So it would be in order 0.99 0.99dev and 0.99~dev (these are indistinguishable) 0.99.1 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. So what's left is either even/odd to indicate release/dev, or .90/.99 to indicate dev. 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 Option 2 1.0, 1.0.1, 1.0.2, ... - release 1.0.90 - dev 1.0.91, 1.0.92 - RC 1.1, 1.1.1, 1.1.2, ... - release -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
In message 4cec7683.2090...@prjek.net on Tue, 23 Nov 2010 20:20:51 -0600, Timothy Brownawell tbrow...@prjek.net said: tbrownaw left over wins, so (blank) will sort first. So it would be in order tbrownaw0.99 tbrownaw0.99dev and 0.99~dev (these are indistinguishable) tbrownaw0.99.1 Oh, so you're interpreting 0.99dev as 0.99 plus development, while I interpret it as development of 0.99 (OpenSSL uses the latter interpretation for that kind of notation). As a matter of fact, I believe that's what we've done in monotone as well, consider the main branch currently has the version 1.0dev ;-) That kind of confusion alone tells me we should probably avoid having that kind of notation... tbrownaw So what's left is either even/odd to indicate release/dev, tbrownaw or .90/.99 to indicate dev. I agree. tbrownaw Option 1 tbrownaw1.0 or 1.0.0, 1.0.1, 1.0.2 - release tbrownaw1.1- dev tbrownaw???- RC tbrownaw1.2, 1.2.1, ...- release tbrownaw tbrownaw Option 2 tbrownaw1.0, 1.0.1, 1.0.2, ... - release tbrownaw1.0.90 - dev tbrownaw1.0.91, 1.0.92 - RC tbrownaw1.1, 1.1.1, 1.1.2, ... - release Shall we vote? In that case, I vote for option 2. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Martin Dvorak wrote: I never was fan of the x.99.x/x.9x/etc. version numbering for betas of new major versions. I've been thinking about stable/development version numbering recently (and also in the past) and I think it's better to call such versions as 1.1-alpha5, 1.1-beta3, 2.0-rc2. This means using the target major version but appending a suffix that marks it's not the final release. What do you think? Are there any issues with this scheme for users and/or automatic tools, such as package managers in Linux? Debian supports this using a tilde to separate the target major version and the suffix, e.g. 1.1~alpha5, 1.1~beta3, 2.0~rc2. I don't know about other distros. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Am 22.11.2010 07:36, schrieb Martin Dvorak: Thomas Keller wrote: We'll have regular minor releases just like before after 1.0 - we only want to assert to support 1.0 with patch releases a little longer than the usual minor releases. I remember we talked about some rules on the list, but never actually jotted them down. I did that now on the RoadMap page [0] - feel free to post corrections and / or updates there. Thomas. [0] http://wiki.monotone.ca/RoadMap/ Hi, I never was fan of the x.99.x/x.9x/etc. version numbering for betas of new major versions. I've been thinking about stable/development version numbering recently (and also in the past) and I think it's better to call such versions as 1.1-alpha5, 1.1-beta3, 2.0-rc2. This means using the target major version but appending a suffix that marks it's not the final release. We already append a suffix dev to development snapshots (i.e. 1.0dev) which get created on build farms like openSUSE's build service. Thomas Moschny said that this is suboptimal because of rpm's version comparison algorithms which would consider 1.0dev newer than 1.0, so whatever we come up for the release numbering (which must have widespread support for rpm, dpkg and friends), should be applied in a similar way to this. Personally I don't care much whether we use numbers or appended strings, as long as the algorithms are smart enough to find 1.0-dev (or whatever) older than 1.0-alpha1 (or whatever). Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On 11/22/2010 07:23 AM, Thomas Keller wrote: We already append a suffix dev to development snapshots (i.e. 1.0dev) which get created on build farms like openSUSE's build service. Thomas Moschny said that this is suboptimal because of rpm's version comparison algorithms which would consider 1.0dev newer than 1.0, so whatever we come up for the release numbering (which must have widespread support for rpm, dpkg and friends), should be applied in a similar way to this. Personally I don't care much whether we use numbers or appended strings, as long as the algorithms are smart enough to find 1.0-dev (or whatever) older than 1.0-alpha1 (or whatever). It looks like what rpm does is: split into all-alpha and all-numeric items, and then sort on string/numeric comparisons of each item, or sort on rand() if an item is numeric on one side and alpha on the other. So if we go with appending strings we'd also have to append one for actual releases which I think has issues, 1.0-dev, 1.0-pre, 1.0-release would sort properly... but then explodes horribly when we want to release a 1.0.1. Using 1.0-release-1 would work, but looks icky. So I think basically rpm requires X.Y.Z even/odd scheme in order to distinguish release/dev. Which is annoying. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On Mon, Nov 22, 2010 at 08:17:38AM -0600, Timothy Brownawell wrote: So I think basically rpm requires X.Y.Z even/odd scheme in order to distinguish release/dev. Which is annoying. The colon classification system had a scheme where some symbols would collate before end-od-string. They used lower-case letters for this, so 75a came before 75 75 came before 75A Are there any such characters for use with the well-known package managers? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On Mon, Nov 22, 2010 at 10:18:47AM -0500, Hendrik Boom wrote: On Mon, Nov 22, 2010 at 08:17:38AM -0600, Timothy Brownawell wrote: So I think basically rpm requires X.Y.Z even/odd scheme in order to distinguish release/dev. Which is annoying. The colon classification system had a scheme where some symbols would collate before end-od-string. They used lower-case letters for this, so 75a came before 75 75 came before 75A Are there any such characters for use with the well-known package managers? Yes, there is one -- the tilde. Here's a part of the DEbian specification for how upstream version numbers (i.e., ours) are to be sorted.I quote from http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version === First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters and so that a tilde sorts before anything, even the end of a part. For example, the following parts are in sorted order from earliest to latest: ~~, ~~a, ~, the empty part, a.[ Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero. These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a difference is found or both strings are exhausted. === This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7, which will sort before version 1.1 This sounds like the numbering system we're looking for. Of course, this isn't the *entire* comparison alrorithm. There's also an epoch and a Debian-specific attachment to the verison number. Check the link above for further details. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On 11/22/2010 09:43 AM, Hendrik Boom wrote: This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7, which will sort before version 1.1 This sounds like the numbering system we're looking for. Of course, this isn't the *entire* comparison alrorithm. There's also an epoch and a Debian-specific attachment to the verison number. Check the link above for further details. Yep, that would be ideal except it looks like rpm-based distros don't support it. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On Mon, Nov 22, 2010 at 05:28:23PM -0600, Timothy Brownawell wrote: On 11/22/2010 09:43 AM, Hendrik Boom wrote: This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7, which will sort before version 1.1 This sounds like the numbering system we're looking for. Of course, this isn't the *entire* comparison alrorithm. There's also an epoch and a Debian-specific attachment to the verison number. Check the link above for further details. Yep, that would be ideal except it looks like rpm-based distros don't support it. Maybe we should log a bug against rpm itself. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On Mon, Nov 22, 2010 at 11:46:49PM -0500, Hendrik Boom wrote: On Mon, Nov 22, 2010 at 05:28:23PM -0600, Timothy Brownawell wrote: On 11/22/2010 09:43 AM, Hendrik Boom wrote: This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7, which will sort before version 1.1 This sounds like the numbering system we're looking for. Of course, this isn't the *entire* comparison alrorithm. There's also an epoch and a Debian-specific attachment to the verison number. Check the link above for further details. Yep, that would be ideal except it looks like rpm-based distros don't support it. Maybe we should log a bug against rpm itself. Maybe we should first find out what the actual specifications are for version numbers in rpm. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
On 11/22/2010 10:48 PM, Hendrik Boom wrote: On Mon, Nov 22, 2010 at 11:46:49PM -0500, Hendrik Boom wrote: On Mon, Nov 22, 2010 at 05:28:23PM -0600, Timothy Brownawell wrote: On 11/22/2010 09:43 AM, Hendrik Boom wrote: This if we add ~dev7 to version number 1.1, we'll get version 1.1~dev7, which will sort before version 1.1 This sounds like the numbering system we're looking for. Of course, this isn't the *entire* comparison alrorithm. There's also an epoch and a Debian-specific attachment to the verison number. Check the link above for further details. Yep, that would be ideal except it looks like rpm-based distros don't support it. Maybe we should log a bug against rpm itself. Maybe we should first find out what the actual specifications are for version numbers in rpm. http://rpm.org/gitweb?p=rpm.git;a=blob_plain;f=lib/rpmvercmp.c;hb=HEAD Numeric segments are newer then alpha segments, anything other than an alnum is a separator and is otherwise ignored. So abc123.de-~f8g has segments abc (alpha), 123 (numeric), de (alpha), f (alpha), 8 (numeric), g (alpha). I also found a perl module earlier today that claimed to have copied an earlier rpm version; that had alpha vs. numeric segments in the same position as arbitrary/undefined but was otherwise the same. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Am 21.11.10 19:14, schrieb Stephen Leake: remember we communicated that 1.0 will be 0.99 + bug fixes, i.e. no new features or breakage. If this is not possible, please do it in a separate branch and we'll merge that for 1.1. I think 'mtn au conflicts store' is more of a polishing than a new feature? But I don't mind holding it for 1.1. We'll have regular minor releases just like before after 1.0 - we only want to assert to support 1.0 with patch releases a little longer than the usual minor releases. I remember we talked about some rules on the list, but never actually jotted them down. I did that now on the RoadMap page [0] - feel free to post corrections and / or updates there. Thomas. [0] http://wiki.monotone.ca/RoadMap/ -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Release rules Was: Re: [Monotone-devel] conflicts store vs show_conflicts
Thomas Keller wrote: We'll have regular minor releases just like before after 1.0 - we only want to assert to support 1.0 with patch releases a little longer than the usual minor releases. I remember we talked about some rules on the list, but never actually jotted them down. I did that now on the RoadMap page [0] - feel free to post corrections and / or updates there. Thomas. [0] http://wiki.monotone.ca/RoadMap/ Hi, I never was fan of the x.99.x/x.9x/etc. version numbering for betas of new major versions. I've been thinking about stable/development version numbering recently (and also in the past) and I think it's better to call such versions as 1.1-alpha5, 1.1-beta3, 2.0-rc2. This means using the target major version but appending a suffix that marks it's not the final release. What do you think? Are there any issues with this scheme for users and/or automatic tools, such as package managers in Linux? bye, Martin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
