[Monotone-devel] Re: Release rules Was: Re: conflicts store vs show_conflicts
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 list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Release rules Was: Re: conflicts store vs show_conflicts
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 than 0.48. 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.*' Another big change, but only for people that follow nvm.*, was the need to re-fetch the whole repository from the new address, in order to avoid having those other nvm.* branches which are not strictly related and risking sending them all again on subsequent syncs. -- Lapo Luchini - http://lapo.it/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: Release rules Was: Re: conflicts store vs show_conflicts
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 former still works, but gives a warning. Or has that changed in 0.99? I certainly agree that it's a somewhat incompatible change. However, it's certainly much less severe than a flag day due to netsync incompatibilities. Maybe in the order of a required db migrate? Another big change, but only for people that follow nvm.*, was the need to re-fetch the whole repository from the new address, in order to avoid having those other nvm.* branches which are not strictly related and risking sending them all again on subsequent syncs. IIUC that's rather because of the infrastructural change on monotone.ca where usher and separate databases are used now, rather than an incompatibility between the monotone versions, is it? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Release rules Was: Re: conflicts store vs show_conflicts
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 with me. =) -- Lapo Luchini - http://lapo.it/ signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: Release rules Was: Re: conflicts store vs show_conflicts
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 exceptions AFAIK (in fact, I never seen an exception myself): usage: pkg_version -t version1 version2 source and (readable shell-script) testcases: http://svn.freebsd.org/viewvc/base/head/usr.sbin/pkg_install/version/ -- Lapo Luchini - http://lapo.it/ “The Magic Words are Squeamish Ossifrage” (Ron Rivest, RSA-129 challenge, 1977) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
