On Wed, Aug 18, 2010 at 03:35:31PM +0200, olafbuddenha...@gmx.net wrote: > On Wed, Aug 18, 2010 at 08:28:45AM +1000, Peter Hutterer wrote: > > > So at some point you will just have to implement it and throw it out > > into the wild. I don't think 1.0 is a good version number to begin > > with [...] > > Why not?
predictabilty. labelling the first public draft of a protocol spec as 1.0 makes people think it's final already. leaving out the version number or marking it as 0.x helps set people's mind to what's going on, even if the _content_ is the same. to rephrase the sentence above "I don't think 1.0 is a good version number to start the public drafting process", which conveys what I wanted to say originally. > Judging by everything I've seen so far, 0.x numbering schemes are always > doomed to fail. The simple truth is that you never know which revision > will turn out to be the one mature enough to get widespead use. Starting > with 0.x just means you will end up with a 0.x version in use forever -- > a look at various parts the free software stack provides plenty of > proof. > > You can just as well start with 1.0, and see where you end up. Probably > the first version ultimately being used will be 3.7 or something -- so > what? In my book, that's still a lot better than 0.17... right, but you also have to - to some degree - do what people expect from other projects and that is that a version 1.0 is stable. And it's certainly easier to argue an API break from 0.2 to 0.3 while the protocol is maturing and less confusing for those not deeply involved in the development cycle too. I remember DBus requiring a define DBUS_API_SUBJECT_TO_CHANGE before including the dbus headers pre 1.0. it's quite easy to argue "well, we told you so" if you break something. Cheers, Peter _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel