Re: Version Numbering -- The great debate

On Sun, Aug 01, 2004 at 12:20:59PM +0800, Christopher Kings-Lynne wrote:
> >>This is more features worth mentioning than we've ever had in a single 
> >>release before -- and if you consider several add-ons which have been 
> >>implemented/improved at the same time (Slony, PL/Java, etc.) it's even 
> >>more momentous.   If this isn't 8.0, then what will be?   
> >
> >
> >I tend to agree, and was about to bring up the point myself.
> 
> I'm in favour of 8.0.  There's a time to be humble and a time for hard 
> work to be properly recognised.

We deploy postgresql as part of an application that goes out to big,
IT-savvy corporations. So far we've shipped 7.2.* and 7.4.* (the
upgrade pain to 7.3 outweighed the benefits, so we put that off
and put it off until 7.4 was available).

8.0.0 suggests, to my customers at least, a brand new release with
either massive re-architecting, many new features or both and that's
likely to be riddled with bugs. While it would be unlikely that we'd
ship 7.5.0 to customers (I suspect there'd be a .1 release before we
were comfortable with the .0 release, given the massive changes)
there's not a chance we'd ship 8.0.0 - even though it's the identical
codebase - because of that perception. Probably not 8.0.1 either.

From the discussions I've seen and the number and size of changes I've
seen go into the codebase recently I suspect 8.0.0 might be quite an
appropriate version number on several levels. There have been a lot of
major changes in this release, some significant enough, I think,
anyway, to justify a bump in major version number.

Those major changes touch the code everywhere (especially nested
transactions - where the breadth of the changes scares me) and are
likely to lead to a number of obscure bugs that will be problematic
and will probably survive through an extended beta period. People are
likely to expect more bugs in a .0.0 release - but that also means
they're likely to be much more tolerant of them ("nice functionality,
but some problematic bugs - but it's a .0.0 release, so we expect some
bugs, but we also expect the .0.2 or .1.0 release to be _really_
good.").

So, from a managing customer expectations POV, 8.0.0 looks an
appropriate version number for at least two major reasons. I'd rather
end-users treat this release as a development/preview release, forgive
the bugs and take a minor release or two before expecting the level of
stability _we_ expect from postgresql - and I suspect that may be
doubly appropriate for the large base of potential win32 users.

Just a perspective from a company that uses and redistributes
PostgreSQL to end-users.

Cheers, Steve