Re: The case for version number inflation - Mailing list pgsql-advocacy

From Susanne Ebrecht
Subject Re: The case for version number inflation
Date
Msg-id 515AB3EE.6060207@2ndquadrant.com
Whole thread Raw
In response to The case for version number inflation  (Josh Berkus <josh@agliodbs.com>)
List pgsql-advocacy
Hello Josh and others,

Am 27.02.2013 23:55, schrieb Josh Berkus:
>
> I'm beginning to think that no matter how much *I* like our version
> numbering scheme, it's hurting us with users because they see the last
> three releases as "version 9".  One of PostgreSQL's best features is
> that we do a new major release every year, meaning that the database is
> improving greatly every year.  To the vast majority of the population,
> our version numbering scheme doesn't tell that story.
>

Also IOS is using "our" kind of version numbers.

There are lots of companies outside where changing a tool version is
more efford to prepare then preparing a visit from British Queen. Even
changing the minor release number isn't possible without having QA
testing it for 6 months and lots of bureau-crazy form getting approval
from the biggest boss.

Especially in ISO 9000 family certificated companies updating a tool is
a huge effort.

My information is that that is one of the reasons why RedHat still use
such an old kernel version.

Last year the German community found a PostgreSQL 7.4 in a device. It is
pretty clear why this happened - 7.4 was the actual release when the
company started to develop the device - the device has had minimum
5-years testing phase before it get onto the market. Two years
development, 5 years testing, let's say 1 year more development because
of negative tests and the device came out two years ago - that makes 10
years - so it isn't suprising that 10 years old software is used.

5-years testing is pretty normal for white ware devices (devices used in
household).

I missed the point - I like our versioning system. I also like to
explain it.
And I like that we are so strict here.
Version x.y.z - when we change z then you can be sure it are really just
bug and security fixes.
When we change y then you have a few new feature but we are still
backward compatible.
When we change x then we changed architecture and maybe we aren't
backward compatible.

In ISO 9000 family cert companies you can say that version x.y is used
instead of x.y.z

You usually need to point out the exact version and you aren't allowed
to change it.

I already discussed a lot that companies should update when .z changed -
but - you know ...
I like to explain again and again and again - to recommend again and
again and again to these companies that when you use PostgreSQL you can
place version x.y in your documents instead of version x.y.z. Of course
it is still risky and violates ISO 9000 family because we don't
guarantee that we never will place new features or architecture changes
in a .z-update.

When you just say version 10, 11, 12, 13 - you don't know if it just was
new feature of architecture changes. Will replication break because
architecture xlog changed or not?

As I said at the beginning - Apple seems to use x.y.z too. And here in
Germany you will find more and more Apple users. Iphone, Mac, Ipad ...

Just my 2ct,

Susanne







--
Dipl. Inf. Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com



pgsql-advocacy by date:

Previous
From: Ian Lawrence Barwick
Date:
Subject: The PostgreSQL homepage and release announcements
Next
From: Simon Riggs
Date:
Subject: Re: The case for version number inflation