1.0 (was: lack of standardization on X11)

[Peter Hutterer]

On Wed, Aug 18, 2010 at 03:35:31PM +0200, olafBuddenhagen at 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