Thread: The case for version number inflation

Folks,

I'm personally fond of our version numbering scheme; without it, we'd be
on PostgreSQL version 23 now.  It's old skool and like other
infrastructure projects we admire, such as Linux, Apache, and FreeBSD.

However, this weekend at SCALE I heard someone who has been using
PostgreSQL for 10 years say "we've had nine major releases".

And you're probably aware of the issue with Amazon Linux, where they
don't distinguish between version 9.1 and 9.2 and thus corrupt people's
databases.

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.

In other words: if we have to explain our version numbering to users all
the time (and we do), then maybe we're doing it wrong.

Further, many projects which used to use "regular" version numbers --
such as Firefox -- have now embraced inflationary version numbers.  So,
maybe it's time to just use the first digit.  The next version would be
10.0, and the version in 2014 would be 11.0.

As a counterargument, few other open source databases use inflationary
version numbers, even the NoSQL ones.

Discuss.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On 02/27/2013 02:55 PM, Josh Berkus wrote:
> Folks,
>
> I'm personally fond of our version numbering scheme; without it, we'd be
> on PostgreSQL version 23 now.  It's old skool and like other
> infrastructure projects we admire, such as Linux, Apache, and FreeBSD.

Exactly, I am pretty sure people know that there have not been just 3
major kernel releases.

>
> However, this weekend at SCALE I heard someone who has been using
> PostgreSQL for 10 years say "we've had nine major releases".

Someone not paying attention:)

>
> And you're probably aware of the issue with Amazon Linux, where they
> don't distinguish between version 9.1 and 9.2 and thus corrupt people's
> databases.
>
> 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.
>
> In other words: if we have to explain our version numbering to users all
> the time (and we do), then maybe we're doing it wrong.
>
> Further, many projects which used to use "regular" version numbers --
> such as Firefox -- have now embraced inflationary version numbers.  So,
> maybe it's time to just use the first digit.  The next version would be
> 10.0, and the version in 2014 would be 11.0.

I for one have no problem with the current system or explaining it to
people. It seems to be an education problem more than a numbering one.
If we start the number inflation versioning then we are left explaining
why we did 'nothing' all those years. Version numbers only have meaning
with context. I drifted away from FireFox because the version numbers
lost context and turned into a marketing tool. We just need to do a
better job supplying the context.

>
> As a counterargument, few other open source databases use inflationary
> version numbers, even the NoSQL ones.


>
> Discuss.
>


--
Adrian Klaver
adrian.klaver@gmail.com

Josh,

* Josh Berkus (josh@agliodbs.com) wrote:
> And you're probably aware of the issue with Amazon Linux, where they
> don't distinguish between version 9.1 and 9.2 and thus corrupt people's
> databases.

That's really, really sad to hear, but I don't think a different way of
versioning would have helped.  If people provide packages without
reading any documentation or understanding what they're packaging,
they're going to make mistakes like this.

> In other words: if we have to explain our version numbering to users all
> the time (and we do), then maybe we're doing it wrong.

I don't think switching to inflationary version numbers would change
what we need to tell users at all- in fact, it might even make things
worse.  How many people worry about upgrading from firefox 19 to 20?

> Further, many projects which used to use "regular" version numbers --
> such as Firefox -- have now embraced inflationary version numbers.  So,
> maybe it's time to just use the first digit.  The next version would be
> 10.0, and the version in 2014 would be 11.0.

That would reduce our ability to distinguish, for our users, truely
major changes to the database code base from more natural progressions.
IOW, as in the past, I expect '10.0' to be "wow, we really changed a
huge amount of stuff, consider this one carefully" while 9.3, 9.4, etc,
are a bit less so.  There's also the consideration about how we might
identify to users which releases can be upgraded with pg_upgrade vs.
those which can't (should that ever happen again..).

Lastly, to put it a bit more explicitly, I feel that it's valuable to
have version numbers which are meaningful and I think that many of ours
users do too.

    Thanks,

        Stephen

On 02/27/2013 02:55 PM, Josh Berkus wrote:

> Further, many projects which used to use "regular" version numbers --
> such as Firefox -- have now embraced inflationary version numbers.  So,
> maybe it's time to just use the first digit.  The next version would be
> 10.0, and the version in 2014 would be 11.0.
>
> As a counterargument, few other open source databases use inflationary
> version numbers, even the NoSQL ones.

Why not....

13

Where it is the 2013 release.... We might end up jumping releases (maybe
there isn't a 14 release) but then it keeps it simple.

JD

>
> Discuss.
>


--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579

On Feb 27, 2013, at 6:25 PM, Stephen Frost wrote:

> Josh,
>
> * Josh Berkus (josh@agliodbs.com) wrote:
>> And you're probably aware of the issue with Amazon Linux, where they
>> don't distinguish between version 9.1 and 9.2 and thus corrupt people's
>> databases.
>
> That's really, really sad to hear, but I don't think a different way of
> versioning would have helped.  If people provide packages without
> reading any documentation or understanding what they're packaging,
> they're going to make mistakes like this.
>
>> In other words: if we have to explain our version numbering to users all
>> the time (and we do), then maybe we're doing it wrong.
>
> I don't think switching to inflationary version numbers would change
> what we need to tell users at all- in fact, it might even make things
> worse.  How many people worry about upgrading from firefox 19 to 20?
>
>> Further, many projects which used to use "regular" version numbers --
>> such as Firefox -- have now embraced inflationary version numbers.  So,
>> maybe it's time to just use the first digit.  The next version would be
>> 10.0, and the version in 2014 would be 11.0.
>
> That would reduce our ability to distinguish, for our users, truely
> major changes to the database code base from more natural progressions.
> IOW, as in the past, I expect '10.0' to be "wow, we really changed a
> huge amount of stuff, consider this one carefully" while 9.3, 9.4, etc,
> are a bit less so.  There's also the consideration about how we might
> identify to users which releases can be upgraded with pg_upgrade vs.
> those which can't (should that ever happen again..).
>
> Lastly, to put it a bit more explicitly, I feel that it's valuable to
> have version numbers which are meaningful and I think that many of ours
> users do too.

I do think it is an interesting point to debate on the version numbering for various reasons - after all, it is
importantto look at elements that could help increase PG's marketability and adoption. 

After reflecting on it for quite a bit (i.e. over the past hour), I'm not sure if changing the version numbering scheme
wouldmake such a difference.  There are many open source and proprietary software projects that have similar numbering
schemesto Postgres and they are also well-documented on when they are making a major change (e.g. there is a big
differencebetween Ruby 1.8 and 1.9 which is clearly stated). 

Perhaps we need to make it clearer in our literature that a change from 9.3 to 9.4 is considered a major release?

And personally, I would question someone's ability to make informed decisions about their data if they do not question
andheavily look into what every single software update provides, major or minor :-) 

Jonathan

On Feb 27, 2013, at 7:14 PM, Joshua D. Drake wrote:

> On 02/27/2013 02:55 PM, Josh Berkus wrote:
>
>> Further, many projects which used to use "regular" version numbers --
>> such as Firefox -- have now embraced inflationary version numbers.  So,
>> maybe it's time to just use the first digit.  The next version would be
>> 10.0, and the version in 2014 would be 11.0.
>>
>> As a counterargument, few other open source databases use inflationary
>> version numbers, even the NoSQL ones.
>
> Why not....
>
> 13
>
> Where it is the 2013 release.... We might end up jumping releases (maybe there isn't a 14 release) but then it keeps
itsimple. 

Actually, the interesting point on that is that it would be similar to how the Ubuntu team handles its releases (e.g.
12.10= release in Oct 2012) - and of course, people are (or at least should be) very careful about OS updates. 

Jonathan

On 02/27/2013 04:48 PM, Selena Deckelmann wrote:
>
>
>
> On Wed, Feb 27, 2013 at 2:55 PM, Josh Berkus <josh@agliodbs.com
> <mailto:josh@agliodbs.com>> wrote:
>
>
>     And you're probably aware of the issue with Amazon Linux, where they
>     don't distinguish between version 9.1 and 9.2 and thus corrupt people's
>     databases.

How is this even possible? PG_VERSION is very clear about what version
is actually running. If Amazon does that, I have a feeling we aren't
doing what we are supposed to do and refusing to start on a mismatched
version.

>
>
> This seems like a case to be made for Postgres to respond more elegantly
> to this situation, possibly by converting blocks on the fly to the newer
> version of the database for writes and being ok with reading previous
> versions of blocks, or simply not writing data to the filesystem when
> the versions don't match.


See above.

> I'll not weigh in on the version number inflation. Seems like a lot of
> epic bikeshedding.

Maybe, and probably considering it comes up every few releases since
1997. :P

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579

2013/2/28 Josh Berkus <josh@agliodbs.com>:
> Folks,
(...)
> As a counterargument, few other open source databases use inflationary
> version numbers, even the NoSQL ones.

I can think of a certain very popular open source database whose numbering
scheme jumps about all over the place without much apparent logic
(5.1 to 5.5, current stable release started at 5.6.10, meaning 5.6.01 ~ 5.6.09
were pre-production releases - I think) but which doesn't seem to have affected
its market share too badly.

Compared to that, PostgreSQL's version numbering is a bastion of sanity
which I - hope - anyone with the requisite skills to handle SQL and/or make
IT-related decisions should be able to grok without too much difficulty.

If PostgreSQL were being pitched as a mass-market consumer product, then
yes it might be worth going through the hassle of a version numbering change
and dealing with the confusion arising from two systems. On the other hand
millions of iOS and Android users don't seem to be *too* fazed by a versioning
system which is at 6.1.2 and 4.2.2 respectively.

(And please, let's not even think about using a cutesy naming scheme -
"Excited Elephant", "Flirty Foreign-Key", "Grumpy Groupby" etcetera ;) )


Ian Barwick

* Selena Deckelmann (selena@chesnok.com) wrote:
> On Wed, Feb 27, 2013 at 2:55 PM, Josh Berkus <josh@agliodbs.com> wrote:
> > And you're probably aware of the issue with Amazon Linux, where they
> > don't distinguish between version 9.1 and 9.2 and thus corrupt people's
> > databases.
>
> This seems like a case to be made for Postgres to respond more elegantly to
> this situation, possibly by converting blocks on the fly to the newer
> version of the database for writes and being ok with reading previous
> versions of blocks, or simply not writing data to the filesystem when the
> versions don't match.

It'd certainly be wonderful, but we're simply not there yet. :)  This
does not excuse poor packaging- that's what the packaging is supposed to
be there to address.

    Thanks,

        Stephen

* Joshua D. Drake (jd@commandprompt.com) wrote:
> On 02/27/2013 04:48 PM, Selena Deckelmann wrote:
> >On Wed, Feb 27, 2013 at 2:55 PM, Josh Berkus <josh@agliodbs.com
> ><mailto:josh@agliodbs.com>> wrote:
> >    And you're probably aware of the issue with Amazon Linux, where they
> >    don't distinguish between version 9.1 and 9.2 and thus corrupt people's
> >    databases.
>
> How is this even possible? PG_VERSION is very clear about what
> version is actually running. If Amazon does that, I have a feeling
> we aren't doing what we are supposed to do and refusing to start on
> a mismatched version.

I'm guessing it's not actually possible like that- but to an end user
who gets some cryptic error message about PG_VERSION mismatches (or
worse, just some "DB failed to start error), it may amount to the same
thing in their mind.

    Thanks,

        Stephen

* Ian Lawrence Barwick (barwick@gmail.com) wrote:
> (And please, let's not even think about using a cutesy naming scheme -
> "Excited Elephant", "Flirty Foreign-Key", "Grumpy Groupby" etcetera ;) )

Well, on that note, I actually have started to become fond of named
releases..  but that's a different story. :)

    Thanks,

        Stephen

On 28 February 2013 01:02, Ian Lawrence Barwick <barwick@gmail.com> wrote:

> (And please, let's not even think about using a cutesy naming scheme -
> "Excited Elephant", "Flirty Foreign-Key", "Grumpy Groupby" etcetera ;) )

Hilarious. I love the thought of "Excited Elephant".

But seriously, that wouldn't help us at all, and would just work against us.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 27 February 2013 22:55, Josh Berkus <josh@agliodbs.com> wrote:

> 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.

Our numbering scheme falls in-between what others do.

Big version numbers imply incompatibility, which mostly we don't do
and scaring people isn't part of the objective here. Yes, some people
make the mistake of thinking nothing has changes, but we wouldn't want
the opposite either - people thinking there was change and giving up
"Oh damn! I'm only compatible with Postgres 8.4, oh well but at least
it has MyGrandad 11 support so we'll use that instead".

We should move to 10.0 only when we have something big to say.
Incrementing the big number every release prevents us from flagging
major changes to the outside world.

Most importantly, if we were going to call this release 10.0, I'd feel
a lot happier committing certain more risky looking patches. Deciding
this at the last minute is kindof confusing there.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Folks,

I'm personally fond of our version numbering scheme; without it, we'd be
on PostgreSQL version 23 now.  It's old skool and like other
infrastructure projects we admire, such as Linux, Apache, and FreeBSD.

However, this weekend at SCALE I heard someone who has been using
PostgreSQL for 10 years say "we've had nine major releases".

And you're probably aware of the issue with Amazon Linux, where they
don't distinguish between version 9.1 and 9.2 and thus corrupt people's
databases.

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.

In other words: if we have to explain our version numbering to users all
the time (and we do), then maybe we're doing it wrong.

Further, many projects which used to use "regular" version numbers --
such as Firefox -- have now embraced inflationary version numbers.  So,
maybe it's time to just use the first digit.  The next version would be
10.0, and the version in 2014 would be 11.0.

As a counterargument, few other open source databases use inflationary
version numbers, even the NoSQL ones.

Discuss.

2013/2/28 Josh Berkus <josh@agliodbs.com>:

Folks,

(...)

As a counterargument, few other open source databases use inflationary
version numbers, even the NoSQL ones.

I can think of a certain very popular open source database whose numbering
scheme jumps about all over the place without much apparent logic
(5.1 to 5.5, current stable release started at 5.6.10, meaning 5.6.01 ~ 5.6.09
were pre-production releases - I think) but which doesn't seem to have affected
its market share too badly.

Compared to that, PostgreSQL's version numbering is a bastion of sanity
which I - hope - anyone with the requisite skills to handle SQL and/or make
IT-related decisions should be able to grok without too much difficulty.

If PostgreSQL were being pitched as a mass-market consumer product, then
yes it might be worth going through the hassle of a version numbering change
and dealing with the confusion arising from two systems. On the other hand
millions of iOS and Android users don't seem to be *too* fazed by a versioning
system which is at 6.1.2 and 4.2.2 respectively.

(And please, let's not even think about using a cutesy naming scheme -
"Excited Elephant", "Flirty Foreign-Key", "Grumpy Groupby" etcetera ;) )


Ian Barwick

On Wed, Feb 27, 2013 at 11:02 PM, Gavin Flower
<GavinFlower@archidevsys.co.nz> wrote:
>
> I hate the Firefox versioning system that they currently use!

Yeah, I've heard loads of complaints about that.

> Try educating Amazon.  You _DO_ have a baseball bat?

I know where you can get one...

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 02/28/2013 08:53 AM, Dave Page wrote:
>
> On Wed, Feb 27, 2013 at 11:02 PM, Gavin Flower
> <GavinFlower@archidevsys.co.nz> wrote:
>>
>> I hate the Firefox versioning system that they currently use!
>
> Yeah, I've heard loads of complaints about that.
>
>> Try educating Amazon.  You _DO_ have a baseball bat?
>
> I know where you can get one...
>

To be honest, this is a non problem. As has been said a millions times
before, we will never make everyone happy. If we start inflating our
numbers, they numbers start to mean less.

Consider that Oracle, is only at 11.

Microsoft uses years to represent their product.

Informix doesn't appear to use any numbers anymore opting for Ultimate
Warehouse Edition and "Choice" edition

We aren't a marketing team. Best we can do is educate and let those who
don't bother to be educated, stay ignorant.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579

Il 27/02/13 23:55, Josh Berkus ha scritto:
> 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".
I kinda like that I can use my soccer-like jersey with "Postgres" and
the number 9 on the back for 5 years! :)

Ciao,
Gabriele

--
  Gabriele Bartolini - 2ndQuadrant Italia
  PostgreSQL Training, Services and Support
  gabriele.bartolini@2ndQuadrant.it | www.2ndQuadrant.it

Selena,

> This seems like a case to be made for Postgres to respond more elegantly to
> this situation, possibly by converting blocks on the fly to the newer
> version of the database for writes and being ok with reading previous
> versions of blocks, or simply not writing data to the filesystem when the
> versions don't match.

It's on the TODO list.  It's just really hard to implement, especially
if you consider the combinational challenge.

Postgres won't start up if the binaries don't match the data ... unless
someone has written a script which replaces the pg_control file :-(

>> (And please, let's not even think about using a cutesy naming scheme -
>> "Excited Elephant", "Flirty Foreign-Key", "Grumpy Groupby" etcetera ;) )

I *really* don't want to see the graphic for Excited Elephant.

On the other hand, I think I already have a graphic for Grumpy Groupby ...


--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

Hi,

I do not particularly like the idea, if anyone has doubts about the
versions can visit the policy page actulizacion of PostgreSQL, which are
all up to date.

Saludos,
Gilberto Castillo
La Habana, Cuba
---
This message was processed by Kaspersky Mail Gateway 5.6.28/RELEASE running at host imx3.etecsa.cu
Visit our web-site: <http://www.kaspersky.com>, <http://www.viruslist.com>

Although likely due to a coincidence, I have seen that Postgres seems to
increment its first digit like clockwork every 5 years, and always changes when
we'd otherwise have a 5 in the second position.

So 8 instead of 7.5, 9 instead of 8.5, so if we continue this, the next releases
would be 9.3, 9.4, and then 10 instead of 9.5.

Prior to that, there was a 6.5 and then 7 instead of 6.6, but that's almost the
same amount.

My understanding is that the major feature change which spawned a first number
increment per version was:

* 9.0 was built-in replication support
* 8.0 was the ability to run natively under Windows rather than needing Cygwin
* 7.0 I'm less clear on, probably adding foreign key support I would guess

So was foreign key support a more major change than other things in 6.x or 7.x
such that it led to a first digit change?  Or was the version change more
arbitrary at that time?

Going forward, if we wish to follow the precedents set before, what kind of new
feature would be major enough, relative to others, to warrant a 10?  If in
doubt, I'd say just keep incrementing 9.x, or arbitrarily switch at 9.5.

-- Darren Duncan

> Most importantly, if we were going to call this release 10.0, I'd feel
> a lot happier committing certain more risky looking patches. Deciding
> this at the last minute is kindof confusing there.

We've always picked version numbers after we had the feature list.  What
features do you feel are on the fence?  I had the impression that
logical replication, for example, was pretty far from being done.

> * 9.0 was built-in replication support
> * 8.0 was the ability to run natively under Windows rather than needing
> Cygwin
> * 7.0 I'm less clear on, probably adding foreign key support I would guess
>
> So was foreign key support a more major change than other things in 6.x
> or 7.x such that it led to a first digit change?  Or was the version
> change more arbitrary at that time?

7.0 was because Postgres became crash-safe, and stopped crashing routinely.

> Going forward, if we wish to follow the precedents set before, what kind
> of new feature would be major enough, relative to others, to warrant a
> 10?  If in doubt, I'd say just keep incrementing 9.x, or arbitrarily
> switch at 9.5.

Well, if we get streaming logical replication in 2014, I'd say that's a
good candidate for 10.0. I don't expect that we'll do 9.4.

We'll have polished off a lot of the items in the major todo list,
binary replication will be "complete" at that stage, we'll have database
federation, and if you look at the cumulative changes between 9.0 and
9.4, it's a whole different database.

Other potential changes I can think of worthy of a major version bump:

* auto-sharding (i.e. "web scale")
* zero-downtime upgrade-in-place
* pluggable API for DB access (i.e. "PostNoSQL")
* a package of other PostSQL features (per Jacob's talk).
* pluggable storage
* robust database federation (although we seem likely to get that at the
same time as logical rep)

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On 1 March 2013 18:19, Josh Berkus <josh@agliodbs.com> wrote:
>> Most importantly, if we were going to call this release 10.0, I'd feel
>> a lot happier committing certain more risky looking patches. Deciding
>> this at the last minute is kindof confusing there.
>
> We've always picked version numbers after we had the feature list.  What
> features do you feel are on the fence?  I had the impression that
> logical replication, for example, was pretty far from being done.

I think we need to avoid making decisions based upon impressions and
spend more time looking at facts, but that is beside the point.

Actually, I wasn't talking about logical replication at all.

> Other potential changes I can think of worthy of a major version bump:
>
> * auto-sharding (i.e. "web scale")
> * zero-downtime upgrade-in-place
> * pluggable API for DB access (i.e. "PostNoSQL")
> * a package of other PostSQL features (per Jacob's talk).
> * pluggable storage
> * robust database federation (although we seem likely to get that at the
> same time as logical rep)

It should be incompatibilities or major architectural changes that
drive this, not simply new features.

And I think we should actually plan things ahead of time, so we can
save up lots of incompatibility patches and apply them all in one
release at the start of the cycle. Block format changes, syntax
changes, behaviour differences etc.

Numbering the release once we've seen what's in it doesn't help planning at all.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

>> We've always picked version numbers after we had the feature list.  What
>> features do you feel are on the fence?  I had the impression that
>> logical replication, for example, was pretty far from being done.
>
> I think we need to avoid making decisions based upon impressions and
> spend more time looking at facts, but that is beside the point.

Who's making decisions?  AFAICT, you and Andres have made most of the
descisions on SLR to date.  I haven't been involved, and am unlikely to
become so, unless SLR reaches the stage of doing beta testing.  So I'm
really unclear on what you're accusing me of, or why you are doing it.

> Actually, I wasn't talking about logical replication at all.

So what features were you talking about?

> It should be incompatibilities or major architectural changes that
> drive this, not simply new features.

That hasn't been our approach in the past.  While I can certainly see
arguments in favor of that approach, I can also see arguments against
it.  Now that we have pg_upgrade, there's an argument to be made that
any series which is pgupgradeable should have the same first version
number, for example.  On the other hand, we've generally done well in
adoption by using the first digit to advertise the presence of major new
features.

I'll also point out that the features mentioned above would almost
certainly require major architectural changes, so these things tend to
go hand-in-hand.  Adding pluggable storage or a pluggable parser would
break a lot of stuff.

> And I think we should actually plan things ahead of time, so we can
> save up lots of incompatibility patches and apply them all in one
> release at the start of the cycle. Block format changes, syntax
> changes, behaviour differences etc.

What changes have we even discussed on -hackers which would affect any
of these things?  To date, the items we've discussed which would
actually affect the file format turned out not to.

> Numbering the release once we've seen what's in it doesn't help planning at all.

It's what we've always done.  If you think a different system would be
better, please outline it.  However, this project has never done well
with requiring specific features for specific releases, so any approach
which implies that is going to meet a lot of argument.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

Related to this:

Apparently MariaDB is arbitrarily bumping their next release up to
version 10 in order to jump "ahead" of Oracle MySQL.  It seems not a
coincidence that they chose a major version number one ahead of Postgres.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

2013/3/2 Josh Berkus <josh@agliodbs.com>:
> Related to this:
>
> Apparently MariaDB is arbitrarily bumping their next release up to
> version 10 in order to jump "ahead" of Oracle MySQL.  It seems not a
> coincidence that they chose a major version number one ahead of Postgres.

After last 10 years has PostgreSQL significantly better reputation
than MySQL or MariaDB - minimally in Czech Republic and higher release
number in MariaDB change nothing if we stay in our quality and we will
enhance performance.

I have list of committed patches and I don't see any patch that have a
weight for jump to version 10. Almost all new features will not be
fully complete in 9.3 - and it will be done in 9.4.

Regards

Pavel

>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
>
>
> --
> Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-advocacy

2013/3/2 Josh Berkus <josh@agliodbs.com>:
> Related to this:
>
> Apparently MariaDB is arbitrarily bumping their next release up to
> version 10 in order to jump "ahead" of Oracle MySQL.

The reasoning behind this, which I've heard from several sources, is to
prevent confusion between MySQL and MariaDB releases, as these will
increasingly diverge.

http://blog.mariadb.org/explanation-on-mariadb-10-0/
http://blog.mariadb.org/what-comes-in-between-mariadb-now-and-mysql-5-6/

> It seems not a coincidence that they chose a major version number one ahead of Postgres.

Is that speculation?

If version/release number is really all that cricitical for acceptance, it might
be an idea to find the current highest release number among all RDBMS
products and increment that by one for the next PostgreSQL release ;)


Regards

Ian Barwick

On 2013.03.01 10:19 AM, Josh Berkus wrote:
> 7.0 was because Postgres became crash-safe, and stopped crashing routinely.

Resilience to crashes by design is certainly a major feature when you didn't
have it before, and worthy of the 7.

So why doesn't http://www.postgresql.org/docs/9.2/static/release-7-0.html make
any mention of this?

You'd think the major reason for the release naming would be highlighted at the
top of that page.

-- Darren Duncan

On Feb 28, 2013, at 12:25 AM, Stephen Frost wrote:

> Josh,
>
> * Josh Berkus (josh@agliodbs.com) wrote:
>> And you're probably aware of the issue with Amazon Linux, where they
>> don't distinguish between version 9.1 and 9.2 and thus corrupt people's
>> databases.
>
> That's really, really sad to hear, but I don't think a different way of
> versioning would have helped.  If people provide packages without
> reading any documentation or understanding what they're packaging,
> they're going to make mistakes like this.
>
>> In other words: if we have to explain our version numbering to users all
>> the time (and we do), then maybe we're doing it wrong.
>
> I don't think switching to inflationary version numbers would change
> what we need to tell users at all- in fact, it might even make things
> worse.  How many people worry about upgrading from firefox 19 to 20?
>
>> Further, many projects which used to use "regular" version numbers --
>> such as Firefox -- have now embraced inflationary version numbers.  So,
>> maybe it's time to just use the first digit.  The next version would be
>> 10.0, and the version in 2014 would be 11.0.
>


hi …

this is exactly the point. nobody will worry if he uses PostgreSQL 78 or PostgreSQL 79 - even if the change is
significantly.
what was said about firefox is absolutely correct - personally i don't care at all and somebody should read the docs
beforedeciding on fundamental infrastructure such as a database. 
maybe i am too conservative but inflation has never solved a problem - not in real life and not in versioning.

    regards,

        hans


--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


Josh Berkus spake:
> 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.

Do you have more than anecdotes to back that up? Not bumping the major
number every release is the norm, not the exception (in the tech world).
More to the point, does it really hurt our uptake to be on version 9.2
instead of version 12?

Simon Riggs wrote:
> Big version numbers imply incompatibility, which mostly we don't do
> and scaring people isn't part of the objective here. Yes, some people
> make the mistake of thinking nothing has changes, but we wouldn't want
> the opposite either - people thinking there was change and giving up
> "Oh damn! I'm only compatible with Postgres 8.4, oh well but at least
> it has MyGrandad 11 support so we'll use that instead".

Of course, we actually are not consistent at all. 7.3 to 7.4 should have
been a major change, and was not. And other major jumps, while adding
lots of new features, certainly did not have incompatibility issues.
Other than a major protocol change, it's hard to argue than *anything*
automatically warrants a major version bump.[1] The key word here
being 'automatically'.

> We should move to 10.0 only when we have something big to say.
> Incrementing the big number every release prevents us from flagging
> major changes to the outside world.

Agreed.

> Most importantly, if we were going to call this release 10.0, I'd feel
> a lot happier committing certain more risky looking patches. Deciding
> this at the last minute is kindof confusing there.

This is putting the cart before the horse, isn't it? Let's commit all
we can, and *then* make the decision as to how worthy the changes are
for a major number bump.

[1] Upon reflection, in-place upgrade qualifies

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201303021402
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlEyTOUACgkQvJuQZxSWSsierACg/KD+TC+1I4Hjt3XOBTQ7jaUv
vEUAnR3VGy5/AXhuDgS4Kdv5vru9U+SZ
=VAra
-----END PGP SIGNATURE-----

On Fri, Mar  1, 2013 at 11:56:44PM -0800, Darren Duncan wrote:
> On 2013.03.01 10:19 AM, Josh Berkus wrote:
> >7.0 was because Postgres became crash-safe, and stopped crashing routinely.
>
> Resilience to crashes by design is certainly a major feature when
> you didn't have it before, and worthy of the 7.
>
> So why doesn't
> http://www.postgresql.org/docs/9.2/static/release-7-0.html make any
> mention of this?
>
> You'd think the major reason for the release naming would be
> highlighted at the top of that page.

6.5 was the big release that should have been 7.0 because of crash
safety.  8.0 and 9.0 were properly numbered based on feature additions.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

I support the arguments in favor of continuing the current version numbering
system. -- Darren Duncan

> I am fine with our current versioning system and I think it works to our
> advantage.  However I do think we could use some extra effort to make sure
> we are on the same page regarding what these numbers mean.

Yes.  Per my previous email, we have always incremented the first digit
because of major features which changed PostgreSQL's position in the
marketplace.  As a PG advocacy geek, I'm reluctant to give that up; the
publicity around 9.0 really did give Postgres adoption a boost, and I
think we can make as much hay out of 10.0.

Personally, I'm thinking that we're more likely to have a 10.0 than a 9.4.

BTW, I'd say this thread has pretty much shot down any idea of changing
our version numbering system.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

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

On 1 March 2013 19:38, Josh Berkus <josh@agliodbs.com> wrote:
>
>>> We've always picked version numbers after we had the feature list.  What
>>> features do you feel are on the fence?  I had the impression that
>>> logical replication, for example, was pretty far from being done.
>>
>> I think we need to avoid making decisions based upon impressions and
>> spend more time looking at facts, but that is beside the point.
>
> Who's making decisions?  AFAICT, you and Andres have made most of the
> descisions on SLR to date.  I haven't been involved, and am unlikely to
> become so, unless SLR reaches the stage of doing beta testing.  So I'm
> really unclear on what you're accusing me of, or why you are doing it.

Josh, for some reason I missed this post earlier, just seen because of
other posts.

I meant my words as a general comment, so not an accusation of any
kind. Since you took it that way, I apologise, especially so since I
ignored your post.

To explain myself further, its difficult to know what will be in or
out of a release until at-least technical triage has been performed on
work to gain facts. Some things are further forward than might be
expected, others disappointingly not ready even after lots of work.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 2 March 2013 01:16, Josh Berkus <josh@agliodbs.com> wrote:
> Related to this:
>
> Apparently MariaDB is arbitrarily bumping their next release up to
> version 10 in order to jump "ahead" of Oracle MySQL.  It seems not a
> coincidence that they chose a major version number one ahead of Postgres.

There's a joke about data loss there somewhere...

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services