Version Numbering

Hackers,

A while ago, I asked if .0 releases could be versioned with three digits instead of two. That is, it would be "8.4.0" instead of "8.4". This is to make the format consistent with maintenance releases ("8.4.1", etc.). I thought this was generally agreed upon, but maybe not, because I just went to build the latest 9.0 beta and saw that the version number is "9.0beta4".

Would it be possible to *always* use three integers? So the next release would be "9.0.0beta5" or "9.0.0rc1"? In addition to being more consistent, it also means that PostgreSQL would be adhering to Semantic Versioning (http://semver.org/), which is a very simple format that's internally consistent. I'm planning to require semantic versioning for PGXN, and it'd be nice if the core could do the same thing (it will make it nicer for specifying dependencies on core contrib modules, for example).

Thanks,

David

On Fri, Aug 20, 2010 at 11:12:56AM -0700, David Wheeler wrote:
> Hackers,
>
> A while ago, I asked if .0 releases could be versioned with three
> digits instead of two. That is, it would be "8.4.0" instead of
> "8.4". This is to make the format consistent with maintenance
> releases ("8.4.1", etc.). I thought this was generally agreed upon,
> but maybe not, because I just went to build the latest 9.0 beta and
> saw that the version number is "9.0beta4".
>
> Would it be possible to *always* use three integers? So the next
> release would be "9.0.0beta5" or "9.0.0rc1"? In addition to being
> more consistent, it also means that PostgreSQL would be adhering to
> Semantic Versioning (http://semver.org/), which is a very simple
> format that's internally consistent. I'm planning to require
> semantic versioning for PGXN, and it'd be nice if the core could do
> the same thing (it will make it nicer for specifying dependencies on
> core contrib modules, for example).

+1 for three-number versions...well, until we really see the light and
go to two-number versions. 8.3 and 8.4 are different enough that they
shouldn't even mildly appear the same, for example.

Cheers,
David (Oh, how silly! You actually want Frobozz 3.1.4.1.5.2.6, not 3.1.4.1.5.2.5!).
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Aug 20, 2010, at 11:34 AM, David Fetter wrote:

> +1 for three-number versions...well, until we really see the light and
> go to two-number versions. 8.3 and 8.4 are different enough that they
> shouldn't even mildly appear the same, for example.

No idea what you mean by that, but generally it's a bad idea to switch from dotted-integer version numbers and numeric version numbers. See Perl (Quel désastre!).

Best,

David

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> A while ago, I asked if .0 releases could be versioned with three
> digits instead of two. That is, it would be "8.4.0" instead of "8.4".

We've been doing that for some time, no? A quick look at the CVS
history shows that 8.0.0 and up were tagged that way.

> This is to make the format consistent with maintenance releases ("8.4.1", etc.). I thought this was generally agreed upon, but maybe not, because I just went to build the latest 9.0 beta and saw that the version number is "9.0beta4".

.0 is for releases, not betas. I see no need for an extra number in
beta versions.

regards, tom lane

On Aug 20, 2010, at 11:40 AM, Tom Lane wrote:

> "David E. Wheeler" <david(at)kineticode(dot)com> writes:
>> A while ago, I asked if .0 releases could be versioned with three
>> digits instead of two. That is, it would be "8.4.0" instead of "8.4".
>
> We've been doing that for some time, no? A quick look at the CVS
> history shows that 8.0.0 and up were tagged that way.

Ah, good for the final release.

>> This is to make the format consistent with maintenance releases ("8.4.1", etc.). I thought this was generally agreed upon, but maybe not, because I just went to build the latest 9.0 beta and saw that the version number is "9.0beta4".
>
> .0 is for releases, not betas. I see no need for an extra number in
> beta versions.

Again, it means the format would be consistent. Always three integers. Nice thing about Semantic Versions is that if you append any ASCII string to the third integer, it automatically means "less than that integer".

Best,

David

On Fri, Aug 20, 2010 at 11:36:55AM -0700, David Wheeler wrote:
> On Aug 20, 2010, at 11:34 AM, David Fetter wrote:
>
> > +1 for three-number versions...well, until we really see the light
> > and go to two-number versions. 8.3 and 8.4 are different enough
> > that they shouldn't even mildly appear the same, for example.
>
> No idea what you mean by that, but generally it's a bad idea to
> switch from dotted-integer version numbers and numeric version
> numbers. See Perl (Quel désastre!).

I'm thinking that after 9.0, the first release of the next major
version should be 10.0, and the one after that, 11.0, etc., etc.

The current system give people the completely false impression that
7.0 and 7.4 are somehow similar.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Aug 20, 2010, at 11:47 AM, David Fetter wrote:

>> No idea what you mean by that, but generally it's a bad idea to
>> switch from dotted-integer version numbers and numeric version
>> numbers. See Perl (Quel désastre!).
>
> I'm thinking that after 9.0, the first release of the next major
> version should be 10.0, and the one after that, 11.0, etc., etc.

Oh. Good luck with that. I disagree, FWIW.

> The current system give people the completely false impression that
> 7.0 and 7.4 are somehow similar.

On what planet?

Best,

David

On Fri, Aug 20, 2010 at 7:34 PM, David Fetter <david(at)fetter(dot)org> wrote:
> +1 for three-number versions...well, until we really see the light and
> go to two-number versions.  8.3 and 8.4 are different enough that they
> shouldn't even mildly appear the same, for example.

You realize if we did that 9.0 would be version 18?

> David (Oh, how silly!  You actually want Frobozz 3.1.4.1.5.2.6, not 3.1.4.1.5.2.5!).

So eventually you end up with the same problem. Oh, you wanted version
117 not 116!

--
greg

On Fri, Aug 20, 2010 at 7:42 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> Again, it means the format would be consistent. Always three integers. Nice thing about Semantic Versions is that if you append any ASCII string to the third integer, it automatically means "less than that integer".
>

So I count three integers in both 9.0rc1 and 9.0beta4

--
greg

On Aug 20, 2010, at 12:02 PM, Greg Stark wrote:

>> Again, it means the format would be consistent. Always three integers. Nice thing about Semantic Versions is that if you append any ASCII string to the third integer, it automatically means "less than that integer".
>>
>
> So I count three integers in both 9.0rc1 and 9.0beta4

No, I mean 9.0.0beta4. If we were to adopt the Semantic Versioning spec, one would *always* use X.Y.Z, with optional ASCII characters appended to Z to add meaning (including "less than unadorned Z).

Best,

David

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Aug 20, 2010, at 12:02 PM, Greg Stark wrote:
>> So I count three integers in both 9.0rc1 and 9.0beta4

> No, I mean 9.0.0beta4. If we were to adopt the Semantic Versioning spec, one would *always* use X.Y.Z, with optional ASCII characters appended to Z to add meaning (including "less than unadorned Z).

Well, I for one will fiercely resist adopting any such standard, because
it's directly opposite to the way that RPM will sort such version numbers.
Apparently whoever wrote "Semantic Versioning" didn't bother to inquire
into existing practice.

regards, tom lane

On Aug 20, 2010, at 12:15 PM, Tom Lane wrote:

>> No, I mean 9.0.0beta4. If we were to adopt the Semantic Versioning spec, one would *always* use X.Y.Z, with optional ASCII characters appended to Z to add meaning (including "less than unadorned Z).
>
> Well, I for one will fiercely resist adopting any such standard, because
> it's directly opposite to the way that RPM will sort such version numbers.

Which is how?

> Apparently whoever wrote "Semantic Versioning" didn't bother to inquire
> into existing practice.

Tom Preston-Warner of GitHub fame.

Best,

David

+1 for Tom's post.

--
Devrim GÜNDÜZ
PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

20.Ağu.2010 tarihinde 21:40 saatinde, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
şunları yazdı:

> "David E. Wheeler" <david(at)kineticode(dot)com> writes:
>> A while ago, I asked if .0 releases could be versioned with three
>> digits instead of two. That is, it would be "8.4.0" instead of "8.4".
>
> We've been doing that for some time, no? A quick look at the CVS
> history shows that 8.0.0 and up were tagged that way.
>
>> This is to make the format consistent with maintenance releases
>> ("8.4.1", etc.). I thought this was generally agreed upon, but
>> maybe not, because I just went to build the latest 9.0 beta and saw
>> that the version number is "9.0beta4".
>
> .0 is for releases, not betas. I see no need for an extra number in
> beta versions.
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

20.Ağu.2010 tarihinde 21:47 saatinde, David Fetter <david(at)fetter(dot)org>
şunları yazdı:
> The current system give people the completely false impression that
> 7.0 and 7.4 are somehow similar.

Well, I do find PostgreSQL versioning policy very good, which is
pretty much similar to Linux. For me, 7.x are similar. Remember why we
jumped from 7.5 to 8.0 or from 8.5 to 9.0.

Cheers,
--
Devrim GÜNDÜZ
PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

On Aug 20, 2010, at 12:21 PM, Devrim GÜNDÜZ wrote:

> +1 for Tom's post.
>
> 20.Ağu.2010 tarihinde 21:40 saatinde, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> şunları yazdı:
>
>> .0 is for releases, not betas. I see no need for an extra number in
>> beta versions.

Yes, well, it's still implicit, isn't it?

David

* David E. Wheeler (david(at)kineticode(dot)com) wrote:
> On Aug 20, 2010, at 12:21 PM, Devrim GÜNDÜZ wrote:
>
> > +1 for Tom's post.
> >
> > 20.Ağu.2010 tarihinde 21:40 saatinde, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> şunları yazdı:
> >
> >> .0 is for releases, not betas. I see no need for an extra number in
> >> beta versions.
>
> Yes, well, it's still implicit, isn't it?

It's still useless garbage.. Sorry, I'm w/ Tom on this one.

THanks,

Stephen

"David E. Wheeler" <david(at)kineticode(dot)com> wrote:

>>> .0 is for releases, not betas. I see no need for an extra
>>> number in beta versions.
>
> Yes, well, it's still implicit, isn't it?

Not the way I read it. If we had a development cycle which resulted
in 8.4.5beta4, then you would have a point. We don't.

Now, if you wanted to argue that it would be better to use 9.0.beta4
than 9.0beta4, that might be defensible. I think I like that
better; but I'm not inclined to think the difference is worth the
pain of changing an established convention.

-Kevin

> Yes, well, it's still implicit, isn't it?

But the last .0 in 9.0.0 is the patch level, effectively. This makes
that .0 inappropriate for betas; the beta number is the patch level,
i.e. 9.0.beta4. It doesn't make any sense to have a 9.0.0beta4, since
we're never going to have a 9.0.2beta4.

The betas are pre-.0. Maybe we should have 9.0.(-3) instead. Or 8.9.97?
;-)

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

20.Ağu.2010 tarihinde 23:03 saatinde, Josh Berkus <josh(at)agliodbs(dot)com>
şunları yazdı:

> The betas are pre-.0. Maybe we should have 9.0.(-3) instead. Or
> 8.9.97?
> ;-)

This is pretty much what Fedora does actually :-)

--
Devrim GÜNDÜZ
PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

On Fri, Aug 20, 2010 at 07:59:55PM +0100, Greg Stark wrote:
> On Fri, Aug 20, 2010 at 7:34 PM, David Fetter <david(at)fetter(dot)org> wrote:
> > +1 for three-number versions...well, until we really see the light
> > and go to two-number versions.  8.3 and 8.4 are different enough
> > that they shouldn't even mildly appear the same, for example.
>
> You realize if we did that 9.0 would be version 18?

Yes. And?

> > David (Oh, how silly!  You actually want Frobozz 3.1.4.1.5.2.6,
> > not 3.1.4.1.5.2.5!).
>
> So eventually you end up with the same problem. Oh, you wanted
> version 117 not 116!

Assuming wild optimism, namely that we release a major version each
year on the exact same date, that will become a problem *long* after
no one in this discussion is still involved with the project. I'm OK
with deferring this to future generations.

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Fri, Aug 20, 2010 at 11:48:12AM -0700, David Wheeler wrote:
> On Aug 20, 2010, at 11:47 AM, David Fetter wrote:
>
> >> No idea what you mean by that, but generally it's a bad idea to
> >> switch from dotted-integer version numbers and numeric version
> >> numbers. See Perl (Quel désastre!).
> >
> > I'm thinking that after 9.0, the first release of the next major
> > version should be 10.0, and the one after that, 11.0, etc., etc.
>
> Oh. Good luck with that. I disagree, FWIW.
>
> > The current system give people the completely false impression
> > that 7.0 and 7.4 are somehow similar.
>
> On what planet?

"We're using Postgre 8"

See also all the flocks of tools that claim to support "Postgres 8"

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On Aug 20, 2010, at 12:15 PM, Tom Lane wrote:
>> Well, I for one will fiercely resist adopting any such standard, because
>> it's directly opposite to the way that RPM will sort such version numbers.

> Which is how?

9.0.0 is less than 9.0.0anything. Unless you wire some specific
knowledge of semantics of particular letter-strings into the comparison
algorithm, it's difficult to come to another decision, IMO.

BTW, 9.0.0 is also less than 9.0.0.anything ... so sticking another dot
in there wouldn't help.

regards, tom lane

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

David Wheeler:

> No idea what you mean by that, but generally it's a bad idea
> to switch from dotted-integer version numbers and numeric
> version numbers. See Perl (Quel dsastre!).

Yeah, I think Perl is a prime example of how NOT to handle
version numbering. :) I think we got it right the first time.

David Fetter:

> "We're using Postgre 8"
>
> See also all the flocks of tools that claim to support "Postgres 8"

Flocks? Handful at best, and no reason we should be catering to
their inaccuracies.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 201008201713
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkxu8NkACgkQvJuQZxSWSsgNVACfYko/YC7SOlMXpavO7JXWSZhp
i7QAoKmPKvNlASLAYfimtnrpg0lk82vh
=aWSL
-----END PGP SIGNATURE-----

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [100820 17:10]:

> BTW, 9.0.0 is also less than 9.0.0.anything ... so sticking another dot
> in there wouldn't help.

Debian's packaging versions "work around" this with the special ~
character, which they define as sorting *before* nothing, meaning
8.4~beta1 < 8.4 < 8.4.0 < 8.4extra

See the deb-version man page for details, a nice convinenct, but yes, a
special cased rule...

But at least it's wildly used ;-)

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

On Fri, 2010-08-20 at 21:17 +0000, Greg Sabino Mullane wrote:

> David Fetter:
>
> > "We're using Postgre 8"
> >
> > See also all the flocks of tools that claim to support "Postgres 8"
>
> Flocks? Handful at best, and no reason we should be catering to
> their inaccuracies.

Depends on the goal. If our goal is to continue to add confusion to the
masses of users we have, you are correct. If our goal is to simplify the
ability for a user to accurately understand the version of PostgreSQL
they are running, then you are wrong.

Joshua D. Drake

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt

On Aug 20, 2010, at 2:10 PM, Tom Lane wrote:

> 9.0.0 is less than 9.0.0anything. Unless you wire some specific
> knowledge of semantics of particular letter-strings into the comparison
> algorithm, it's difficult to come to another decision, IMO.

That's what Semantic versions do. From the spec's #3:

> A special version number MAY be denoted by appending an arbitrary string immediately following the patch version. The string MUST be comprised of only alphanumerics plus dash [0-9A-Za-z-] and MUST begin with an alpha character [A-Za-z]. Special versions satisfy but have a lower precedence than the associated normal version. Precedence SHOULD be determined by lexicographic ASCII sort order. For instance: 1.0.0beta1 < 1.0.0beta2 < 1.0.0.

I'm comfortable with this because it's consistent with what people expect when they read a version number.

Best,

David

On Fri, Aug 20, 2010 at 1:48 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Aug 20, 2010, at 11:47 AM, David Fetter wrote:
>
>> The current system give people the completely false impression that
>> 7.0 and 7.4 are somehow similar.
>
> On what planet?
>

Look at other DBMSes:
Oracle: 8i, 9i, 10g, 11g
Informix 9, 10, 11
MS SQL Server 7, 2000, 2005, 2008

note the lack of dotes (and even if they actually have dots, those are
minor versions).

is not only confusing but make people think we are somehow behind the
others... someone actually told me that Oracle is in version 11 we
only in version 8 so Oracle should have more features...
no that i follow that reasoning but...

--
Jaime Casanova         www.2ndQuadrant.com
Soporte y capacitación de PostgreSQL

On Fri, Aug 20, 2010 at 04:41:20PM -0500, Jaime Casanova wrote:
> On Fri, Aug 20, 2010 at 1:48 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> > On Aug 20, 2010, at 11:47 AM, David Fetter wrote:
> >
> >> The current system give people the completely false impression
> >> that 7.0 and 7.4 are somehow similar.
> >
> > On what planet?
>
> Look at other DBMSes:
> Oracle: 8i, 9i, 10g, 11g
> Informix 9, 10, 11
> MS SQL Server 7, 2000, 2005, 2008
>
> note the lack of dotes (and even if they actually have dots, those
> are minor versions).

Some people dote on dots.

> is not only confusing but make people think we are somehow behind
> the others... someone actually told me that Oracle is in version 11
> we only in version 8 so Oracle should have more features... no that
> i follow that reasoning but...

"This one goes up to 11!" ;)

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> Look at other DBMSes:
> Oracle: 8i, 9i, 10g, 11g
> Informix 9, 10, 11
> MS SQL Server 7, 2000, 2005, 2008
>
> note the lack of dotes (and even if they actually have dots, those are
> minor versions).
>

So your proposal is that we name the next release of Postres 9i?

I don't think looking at some of the most industry worst practices
driven by marketing goals unconnected with the product features is
going to help us in any way.

In any case those are all marketing brand names. The actual releases
do in fact have real version numbers and no, they aren't all minor
releases. Oracle 8i was 8.1.x which was indeed a major release over
8.0.

--
greg

On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>> Look at other DBMSes:
>> Oracle: 8i, 9i, 10g, 11g
>> Informix 9, 10, 11
>> MS SQL Server 7, 2000, 2005, 2008
>>
>> note the lack of dotes (and even if they actually have dots, those are
>> minor versions).
>>
>
> So your proposal is that we name the next release of Postres 9i?
>

well, i'm not proposing anything... just showing that our numbering
scheme *is* confusing

>
> In any case those are all marketing brand names. The actual releases
> do in fact have real version numbers and no, they aren't all minor
> releases. Oracle 8i was 8.1.x which was indeed a major release over
> 8.0.
>

Maybe we can give marketing brand names to every new version so people
is not confused by numbers...

--
Jaime Casanova         www.2ndQuadrant.com
Soporte y capacitación de PostgreSQL

On Fri, Aug 20, 2010 at 10:55 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>> In any case those are all marketing brand names. The actual releases
>> do in fact have real version numbers and no, they aren't all minor
>> releases. Oracle 8i was 8.1.x which was indeed a major release over
>> 8.0.
>>
>
> Maybe we can give marketing brand names to every new version so people
> is not confused by numbers...

I can't tell whether you're being sarcastic or not. The whole point of
those marketing names *is* to confuse users.

--
greg

On Aug 20, 2010, at 5:55 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
>> On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>>> Look at other DBMSes:
>>> Oracle: 8i, 9i, 10g, 11g
>>> Informix 9, 10, 11
>>> MS SQL Server 7, 2000, 2005, 2008
>>>
>>> note the lack of dotes (and even if they actually have dots, those are
>>> minor versions).
>>>
>>
>> So your proposal is that we name the next release of Postres 9i?
>>
>
> well, i'm not proposing anything... just showing that our numbering
> scheme *is* confusing
>
>>
>> In any case those are all marketing brand names. The actual releases
>> do in fact have real version numbers and no, they aren't all minor
>> releases. Oracle 8i was 8.1.x which was indeed a major release over
>> 8.0.
>>
>
> Maybe we can give marketing brand names to every new version so people
> is not confused by numbers...

Ah, yes. Because it's so intuitive that Windows 7 comes after Windows 95... :-)

...Robert

On 20 August 2010 23:10, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Aug 20, 2010, at 5:55 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>> On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
>>> On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>>>> Look at other DBMSes:
>>>> Oracle: 8i, 9i, 10g, 11g
>>>> Informix 9, 10, 11
>>>> MS SQL Server 7, 2000, 2005, 2008
>>>>
>>>> note the lack of dotes (and even if they actually have dots, those are
>>>> minor versions).
>>>>
>>>
>>> So your proposal is that we name the next release of Postres 9i?
>>>
>>
>> well, i'm not proposing anything... just showing that our numbering
>> scheme *is* confusing
>>
>>>
>>> In any case those are all marketing brand names. The actual releases
>>> do in fact have real version numbers and no, they aren't all minor
>>> releases. Oracle 8i was 8.1.x which was indeed a major release over
>>> 8.0.
>>>
>>
>> Maybe we can give marketing brand names to every new version so people
>> is not confused by numbers...
>
> Ah, yes. Because it's so intuitive that Windows 7 comes after Windows 95... :-)
>
> ...Robert

A colleague of mine wrote this which might be of interest, and it
mentions both Windows and PostgreSQL:
http://rwec.co.uk/blog/2010/02/golden-rules-of-version-naming/

--
Thom Brown
Registered Linux user: #516935

On Fri, 2010-08-20 at 18:10 -0400, Robert Haas wrote:
> >
> >
> > Maybe we can give marketing brand names to every new version so people
> > is not confused by numbers...
>
> Ah, yes. Because it's so intuitive that Windows 7 comes after Windows 95... :-)

Not really a comparable argument. I find it interesting that people are
making logical arguments about something that is clearly not in the
logical realm. This is marketing people.

Windows 7 works because it is > than Windows Vista. It sounds, looks and
feels greater. It also certainly doesn't hurt that they have billions
for marketing.

JD

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt

> Not really a comparable argument. I find it interesting that people are
> making logical arguments about something that is clearly not in the
> logical realm. This is marketing people.

Then why are we discussing it on -hackers?

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

On Fri, 2010-08-20 at 15:41 -0700, Josh Berkus wrote:
> > Not really a comparable argument. I find it interesting that people are
> > making logical arguments about something that is clearly not in the
> > logical realm. This is marketing people.
>
> Then why are we discussing it on -hackers?

Good point :D

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

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt

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

> Then why are we discussing it on -hackers?

Because you will need buy in from the hackers if you
ever want to do something as radical as change to
a two-number, one dot system (or some the slightly
less radical earlier suggestions). For the record,
I'm with Tom on this: -1 to any changes.

I do like the Ubuntu/Debian way of naming the releases
with some sort of non-numeric name though. :)

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 201008202036
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkxvH+EACgkQvJuQZxSWSshfdwCgxutLw7s2o225qvhKRXeJzvwo
xVgAnAoptFyCTKljX52q7RTsGElDHswE
=yS2/
-----END PGP SIGNATURE-----

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

>> Flocks? Handful at best, and no reason we should be catering to
>> their inaccuracies.

> Depends on the goal. If our goal is to continue to add confusion to the
> masses of users we have, you are correct. If our goal is to simplify the
> ability for a user to accurately understand the version of PostgreSQL
> they are running, then you are wrong.

Are we adding confusion? Do you have any proof to back up that assertion?
I'm pretty sure the masses can handle the fact that 9.1.x is going to
come after 9.0.x, and that 9.0.1 is an bug fix for 9.0.0.

True, we don't always have the best track record for bumping major
releases. (ponders) Hmmm...I'm rethinking my immediate rejection of the
idea now. 7.3 to 7.4 should have been 7.3 to 8.0. Certainly it was more
major than 8.0 to 8.1 was, for example. Consider me a very weak -1
and open to persuasion. :)

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 201008202130
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkxvLGQACgkQvJuQZxSWSsjIoQCfY4ANKov5TV/PDV+mc0Rhda5O
wskAoMjZ4y9t+VOlP+84NMfz7Ws1aNVV
=qRMV
-----END PGP SIGNATURE-----

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

> Look at other DBMSes:
> Oracle: 8i, 9i, 10g, 11g
> Informix 9, 10, 11
> MS SQL Server 7, 2000, 2005, 2008

> is not only confusing but make people think we are somehow behind the
> others... someone actually told me that Oracle is in version 11 we
> only in version 8 so Oracle should have more features...
> no that i follow that reasoning but...

Well by that reasoning SQL Server 2008 is a quantum leap ahead of Oracle!

Frankly, that 'someone' should be hit hard with a clue stick and be
forced to keep 50 feet away from all computers.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 201008202135
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkxvLZAACgkQvJuQZxSWSsjFcQCeMQX9fQcLZVv6q1wssFIsIMQE
INAAoJPEsMRsezdT2bAWP8xLZ7wSpxvh
=yKn1
-----END PGP SIGNATURE-----

On Sat, 2010-08-21 at 01:31 +0000, Greg Sabino Mullane wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> >> Flocks? Handful at best, and no reason we should be catering to
> >> their inaccuracies.
>
> > Depends on the goal. If our goal is to continue to add confusion to the
> > masses of users we have, you are correct. If our goal is to simplify the
> > ability for a user to accurately understand the version of PostgreSQL
> > they are running, then you are wrong.
>
> Are we adding confusion? Do you have any proof to back up that assertion?
> I'm pretty sure the masses can handle the fact that 9.1.x is going to
> come after 9.0.x, and that 9.0.1 is an bug fix for 9.0.0.

As I said previously. I am constantly educated new and old customers on
proper versioning. I *know* I am not the only one that has this problem.

> True, we don't always have the best track record for bumping major
> releases. (ponders) Hmmm...I'm rethinking my immediate rejection of the
> idea now. 7.3 to 7.4 should have been 7.3 to 8.0. Certainly it was more
> major than 8.0 to 8.1 was, for example. Consider me a very weak -1
> and open to persuasion. :)

Are we losing something by going to a notably simpler scheme of
versioning? Is there a problem we are creating? Are we arguing for the
sake of arguing?

Sincerely,

Joshua D. Drake

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt

On Sat, 2010-08-21 at 01:36 +0000, Greg Sabino Mullane wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> > Look at other DBMSes:
> > Oracle: 8i, 9i, 10g, 11g
> > Informix 9, 10, 11
> > MS SQL Server 7, 2000, 2005, 2008
>
> > is not only confusing but make people think we are somehow behind the
> > others... someone actually told me that Oracle is in version 11 we
> > only in version 8 so Oracle should have more features...
> > no that i follow that reasoning but...
>
> Well by that reasoning SQL Server 2008 is a quantum leap ahead of Oracle!

Do we really want to have that argument :P

JD
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt

On Aug 20, 2010, at 5:38 PM, Greg Sabino Mullane wrote:

>> Then why are we discussing it on -hackers?
>
> Because you will need buy in from the hackers if you
> ever want to do something as radical as change to
> a two-number, one dot system (or some the slightly
> less radical earlier suggestions). For the record,
> I'm with Tom on this: -1 to any changes.

It's already a three-integer system for non-dev/alpha/rc releases. So I think it's fine the way it is (and easy enough to convert to semantic versions for comparative purposes, if necessary).

So: WORMS: Back in the can!

Best,

David

On Fri, Aug 20, 2010 at 2:12 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> Would it be possible to *always* use three integers? So the next release would be "9.0.0beta5" or "9.0.0rc1"? In addition to being more consistent, it also means that PostgreSQL would be adhering to Semantic Versioning (http://semver.org/), which is a very simple format that's internally consistent. I'm planning to require semantic versioning for PGXN, and it'd be nice if the core could do the same thing (it will make it nicer for specifying dependencies on core contrib modules, for example).

One thing that may be worth noting here is that even if we implemented
this policy (and the consensus seems to be against it at the moment),
we wouldn't be in compliance with semantic versioning, because our use
of the first two components of the version number does not match that
specification, and we aren't likely to make them match in the future.

What that would mean is that certain kinds of changes would FORCE us
to bump the major revision, and by historical precedent, pretty much
every release cycle would have some. I've occasionally thought that
it would be interesting to have something in between point releases
and major releases, where, perhaps, we would implement changes that
are more than what we'd allow for a minor version bump but nothing too
invasive; and then use major releases for the real big stuff. But the
problem with this is that it would greatly complicate development and
testing and I think in the end we'd end up with a less reliable
product and a lot more arguing about which branches things went into.
I think the semantic versioning approach makes sense for libraries,
but it is not too clear to me that it makes sense for other kinds of
applications. YMMV, of course.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Aug 20, 2010, at 7:49 PM, Robert Haas wrote:

> I think the semantic versioning approach makes sense for libraries,
> but it is not too clear to me that it makes sense for other kinds of
> applications. YMMV, of course.

Yeah, I'm more concerned about determining dependencies in extensions and core than I am why the various parts of version numbers are incremented.

Best,

David

On Fri, Aug 20, 2010 at 10:43 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>> True, we don't always have the best track record for bumping major
>> releases. (ponders) Hmmm...I'm rethinking my immediate rejection of the
>> idea now. 7.3 to 7.4 should have been 7.3 to 8.0. Certainly it was more
>> major than 8.0 to 8.1 was, for example. Consider me a very weak -1
>> and open to persuasion. :)
>
> Are we losing something by going to a notably simpler scheme of
> versioning? Is there a problem we are creating? Are we arguing for the
> sake of arguing?

It's possible that we're arguing for the sake of arguing, but it's so
much easier to have an opinion on version numbering than to have an
opinion on how to fix dependency problems in parallel restore. So
maybe we're all just letting off some steam.

With respect to simplifying the version numbering schema, I kind of
like the one we have, nonwithstanding the problems it creates (namely,
that people think 8.3.0 to 8.4.0 is a smaller change than it really
is; for some reason, they also tend to think 8.4.0 to 8.4.1 is a
bigger change than it really is; and of course they also think that
8.1.0 to 8.2.0 is the same size change as 8.2.0 to 8.3.0, which isn't
true either). It's nice to be able to keep track of the major version
number without running out of fingers (at least for a few more years)
and it's nice to be able to bump the major version number when we do
something to totally destabilize the tree^W^W^W^W^Wreally cool. Or at
least, I think it's nice. Again, YMMV, IMHO, etc.

If the Windows port was the primary justification for the 8.0
designation, and HS/SR are the justification for the 9.0 designation,
what will 10.0 be?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

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

> It's possible that we're arguing for the sake of arguing

No it's not! ;)

> It's nice to be able to keep track of the major version
> number without running out of fingers (at least for a few more years)
> and it's nice to be able to bump the major version number when we do
> something to totally destabilize the tree^W^W^W^W^Wreally cool. Or at
> least, I think it's nice. Again, YMMV, IMHO, etc.
>
> If the Windows port was the primary justification for the 8.0
> designation, and HS/SR are the justification for the 9.0 designation,
> what will 10.0 be?

Therein lies the problem: our decision to do a "major" bump is inconsistent
at best, and wildy confusing at worst. Does a new feature really constitute
a major bump? Perhaps so, as with 9.0 SR/HS, but in that case there have been
other times we should have bumped the major for some new feature and did not.
What about major internal changes and libpq version bumps? You might think
those would always be a major change, but they are not. We went from 7.2
to 7.3 without considering how major it is (hello, schemas!). What about
end-user compatiblity? I sometimes suspect few hackers on this list realize how
completely disruptive, annoying, and painful the removal of implicit
casts was in 8.3. That would have been a major bump in my book at least.

I think in the future we should consider lowering the bar for a "major"
release, as it's better to err on that side.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
PGP Key: 0x14964AC8 201008202330
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkxvSS0ACgkQvJuQZxSWSsjQ0QCfW/2l065L0XEO6kmnARpjgqJ5
t2EAn3xM8w5f5xmHl3EZAmXhxXFpEREo
=/CYr
-----END PGP SIGNATURE-----

On 08/20/2010 09:04 PM, David E. Wheeler wrote:
> On Aug 20, 2010, at 12:02 PM, Greg Stark wrote:
>
>>> Again, it means the format would be consistent. Always three integers. Nice thing about Semantic Versions is that if you append any ASCII string to the third integer, it automatically means "less than that integer".
>>>
>>
>> So I count three integers in both 9.0rc1 and 9.0beta4
>
> No, I mean 9.0.0beta4. If we were to adopt the Semantic Versioning spec, one would *always* use X.Y.Z, with optional ASCII characters appended to Z to add meaning (including "less than unadorned Z).

hmm FWIW I would interpret something like 9.0.1B4 as the forth beta
release for the first point release of the major release 9.0 bis seems
stupid and is not anything we have done before.

You could argue that 9.0.0B4 is the foourth beta for the first
production release of 9.0 but I find the current naming much more
reasonable...

Stefan

On Aug 21, 2010, at 1:45 AM, Stefan Kaltenbrunner wrote:

> hmm FWIW I would interpret something like 9.0.1B4 as the forth beta
> release for the first point release of the major release 9.0 bis seems
> stupid and is not anything we have done before.

It does't make sense for PostgreSQL, no.

> You could argue that 9.0.0B4 is the foourth beta for the first
> production release of 9.0 but I find the current naming much more
> reasonable...

Yeah, it's just semantics, really.

Best,

David

On Sat, Aug 21, 2010 at 03:34:35AM -0000, Greg Sabino Mullane wrote:
> > It's possible that we're arguing for the sake of arguing
>
> No it's not! ;)

Yes it is! ;)

> > It's nice to be able to keep track of the major version number
> > without running out of fingers (at least for a few more years) and
> > it's nice to be able to bump the major version number when we do
> > something to totally destabilize the tree^W^W^W^W^Wreally cool.
> > Or at least, I think it's nice. Again, YMMV, IMHO, etc.
> >
> > If the Windows port was the primary justification for the 8.0
> > designation, and HS/SR are the justification for the 9.0
> > designation, what will 10.0 be?
>
> Therein lies the problem: our decision to do a "major" bump is
> inconsistent at best, and wildy confusing at worst. Does a new
> feature really constitute a major bump? Perhaps so, as with 9.0
> SR/HS, but in that case there have been other times we should have
> bumped the major for some new feature and did not. What about major
> internal changes and libpq version bumps? You might think those
> would always be a major change, but they are not. We went from 7.2
> to 7.3 without considering how major it is (hello, schemas!). What
> about end-user compatiblity? I sometimes suspect few hackers on this
> list realize how completely disruptive, annoying, and painful the
> removal of implicit casts was in 8.3. That would have been a major
> bump in my book at least.
>
> I think in the future we should consider lowering the bar for a
> "major" release, as it's better to err on that side.

"Disruptive to developers" is one sufficient criterion.

Another is "does some big thing simply that would have been hard or
impossible before."

Previous things like dblink, schemas and CTEs, and upcoming things
like synchronous replication, SQL/MED, parallel query, and (of course
;) writeable CTEs, would qualify under that second.

Open for discussion would be features like "Can spit out, on demand,
any subset of the dependency graph for an object."

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate