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
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
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
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
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???
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 |
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
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.
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,
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
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:
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
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.
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
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
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
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
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
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
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
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,
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
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
23 matches
Mail list logo
