Re: The case for version number inflation

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