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

2010-11-25 Thread Lapo Luchini
Markus Wanner wrote: Then we also had database migrations, where a one-way upgarde is possible, but not backwards. Well, not exactly. I did (manually) downgrade a database, one time. =) -- Lapo Luchini - http://lapo.it/ ___ Monotone-devel mailing

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

2010-11-25 Thread Lapo Luchini
Markus Wanner wrote: 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

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

2010-11-25 Thread Markus Wanner
On 11/25/2010 06:10 PM, Lapo Luchini wrote: Well, for me 0.47→0.99 had the *incompatibility* you are talking about, in the instance of the changed method to synchronize with server which needed a change of habits from: mtn sy lapo.it 'it.*' to mtn sy 'mtn://lapo.it/?it.*' IIRC the

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

2010-11-24 Thread Lapo Luchini
Richard Levitte wrote: tbrownaw Option 1 (even/odd) tbrownaw Option 2 (.9x as rc) Shall we vote? In that case, I vote for option 2. I don't really like 90 as a magic number, but OTOH option 1 doesn't have a clear way to say it's a pre-release of next version; both options are perfectly OK

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

2010-11-23 Thread Lapo Luchini
Richard Levitte wrote: How does the algorithm compare when one of the version has a segment empty and the other doesn't in corresponding positions? FreeBSD has got an official system tool to check the ordering of two package revisions, which supports most of the FreeBSD Ports without need for