Gavin Flower wrote:
> I hate the rampant inflation associated with numbering schemes like FireFox
> - the numbers of no meaning at all, other than something non-trivial has
> been changed, with no indication at all about how non-trivial!
I thought this horse had already been beaten to death -- ap
On 21/06/16 03:53, Mark Dilger wrote:
On Jun 18, 2016, at 5:48 PM, Josh Berkus wrote:
On 06/16/2016 11:01 PM, Craig Ringer wrote:
I thought about raising this, but I think in the end it's replacing one
confusing and weird versioning scheme for another confusing and weird
versioning scheme.
It
On 06/20/2016 10:14 PM, Robert Haas wrote:
On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
wrote:
10.x is the desired output.
10.x is the output that some people desire.
(explicitly skipped up-thread to add this -- please forgive my jumping in)
Since we are still (as a community) debatin
On 20/06/2016 22:41, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>>> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
>>> wrote:
10.x is the desired output.
>>
>>> 10.x is the output that some people desire. A significant number of
>>> people, including me, would prefer
On Mon, Jun 20, 2016 at 05:11:17PM -0400, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:55 PM, Tom Lane wrote:
> > No, the argument for it was that we'd no longer have to have the annual
> > discussions about "is it 10.0 yet?".
>
> WHAT annual argument? Did anyone even argue that any 9.x releas
On Mon, May 16, 2016 at 10:16:48AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 5/16/16 9:53 AM, Greg Stark wrote:
> >> I thought the idea was that Berkeley tossed an source tree over the
> >> wall with no version number and then the first five releases were
> >> Postgres95 0.x, Postgr
On Mon, Jun 20, 2016 at 5:36 PM, David G. Johnston
wrote:
>> Yeah, no kidding. We had a perfectly good consensus to keep this at
>> 9.6 on pgsql-advocacy, and then later we had a revised consensus to
>> retitle it to 10.0,
>
> If -advocacy had changed their mind before beta1 was tagged this may h
On Mon, Jun 20, 2016 at 5:08 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake
> wrote:
> > Or we could adopt the very reasonable and practical policy of:
> >
> > The current versioning scheme isn't broke, so we aren't going to fix it.
>
> Yeah, no kidding. We had a perf
On 06/20/2016 02:14 PM, Merlin Moncure wrote:
On Mon, Jun 20, 2016 at 4:08 PM, Robert Haas wrote:
On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake wrote:
Or we could adopt the very reasonable and practical policy of:
The current versioning scheme isn't broke, so we aren't going to fix it.
On Mon, Jun 20, 2016 at 4:08 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake
> wrote:
>> Or we could adopt the very reasonable and practical policy of:
>>
>> The current versioning scheme isn't broke, so we aren't going to fix it.
>
> The idea that this discussion is no
On Mon, Jun 20, 2016 at 4:55 PM, Tom Lane wrote:
> No, the argument for it was that we'd no longer have to have the annual
> discussions about "is it 10.0 yet?".
WHAT annual argument? Did anyone even argue that any 9.x release
prior to 9.6 deserved to be called 10.0? Maybe somebody suggested
th
On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake wrote:
> Or we could adopt the very reasonable and practical policy of:
>
> The current versioning scheme isn't broke, so we aren't going to fix it.
Yeah, no kidding. We had a perfectly good consensus to keep this at
9.6 on pgsql-advocacy, and the
Alvaro Herrera writes:
> Tom Lane wrote:
>> If we were going to do it like that, I would argue for "every ten years
>> like clockwork", e.g. 10.0.x is next after 9.9.x. But in point of fact,
>> Robert, you already made your case for that approach and nobody else
>> cared for it.
> I voted for th
On Mon, Jun 20, 2016 at 4:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
>> wrote:
>>> 10.x is the desired output.
>
>> 10.x is the output that some people desire. A significant number of
>> people, including me, would prefer to stick with the
On 06/20/2016 01:41 PM, Alvaro Herrera wrote:
Tom Lane wrote:
Robert Haas writes:
On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
wrote:
If we were going to do it like that, I would argue for "every ten years
like clockwork", e.g. 10.0.x is next after 9.9.x. But in point of fact,
Rober
Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
> > wrote:
> >> 10.x is the desired output.
>
> > 10.x is the output that some people desire. A significant number of
> > people, including me, would prefer to stick with the current
> > three-part vers
On Mon, Jun 20, 2016 at 4:14 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
> wrote:
> > 10.x is the desired output.
>
> 10.x is the output that some people desire. A significant number of
> people, including me, would prefer to stick with the current
> three-part v
Robert Haas writes:
> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
> wrote:
>> 10.x is the desired output.
> 10.x is the output that some people desire. A significant number of
> people, including me, would prefer to stick with the current
> three-part versioning scheme, possibly with som
On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
wrote:
> 10.x is the desired output.
10.x is the output that some people desire. A significant number of
people, including me, would prefer to stick with the current
three-part versioning scheme, possibly with some change to the
algorithm for bu
> On Jun 20, 2016, at 1:00 PM, David G. Johnston
> wrote:
>
> On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger wrote:
>
> > Do you have a problem with the human form and machine forms of the version
> > number being different in this respect? I don't - for me the decision of a
> > choice for t
On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger
wrote:
>
> > Do you have a problem with the human form and machine forms of the
> version number being different in this respect? I don't - for me the
> decision of a choice for the human form is not influenced by the fact the
> machine form has 6 dig
On Mon, Jun 20, 2016 at 3:07 PM, Gražvydas Valeika
wrote:
> Hi,
>
> I recently bumped into http://semver.org/
>
> It can be interesting to participants of this discussion.
>
> Especially motivation for minor version (middle number).
>
>
While we appreciate the comment this is third (maybe forth)
> On Jun 20, 2016, at 11:30 AM, David G. Johnston
> wrote:
>
> On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger wrote:
>
> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake
> > wrote:
> >
> > On 06/20/2016 10:45 AM, Mark Dilger wrote:
> >
> >>> Now maybe you have some other idea in mind, but I do
Hi,
I recently bumped into http://semver.org/
It can be interesting to participants of this discussion.
Especially motivation for minor version (middle number).
Best,
Grazvydas
On Mon, Jun 20, 2016 at 9:30 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Jun 20, 2016 at
On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger
wrote:
>
> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake
> wrote:
> >
> > On 06/20/2016 10:45 AM, Mark Dilger wrote:
> >
> >>> Now maybe you have some other idea in mind, but I don't quite
> >>> understand what it is.
> >>
> >> I do, indeed, and her
On Mon, Jun 20, 2016 at 1:48 PM, Mark Dilger
wrote:
>
> > On Jun 20, 2016, at 9:38 AM, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
> >
> > On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger
> wrote:
> >
> > > On Jun 20, 2016, at 8:53 AM, Mark Dilger
> wrote:
> > >
> > >
> > > This is no
> On Jun 20, 2016, at 11:06 AM, Joshua D. Drake wrote:
>
> On 06/20/2016 10:45 AM, Mark Dilger wrote:
>
>>> Now maybe you have some other idea in mind, but I don't quite
>>> understand what it is.
>>
>> I do, indeed, and here it is:
>>
>> When considering whether to *back port* a change, we t
Mark Dilger wrote:
> When considering whether to *back port* a change, we typically do so
> on the basis that bug fixes are back ported, features are not. In my
> proposed versioning scheme, you could back port any feature that is
> compatible with the old version, and bump the middle number to a
> On Jun 20, 2016, at 9:38 AM, David G. Johnston
> wrote:
>
> On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger wrote:
>
> > On Jun 20, 2016, at 8:53 AM, Mark Dilger wrote:
> >
> >
> > This is not a plea for keeping the three part versioning system. It's just
> > a plea not to have a 2 part ver
> On Jun 20, 2016, at 9:43 AM, Robert Haas wrote:
>
> On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger wrote:
>>> In practical effect that is exactly what your proposal does. You just feel
>>> better because you defined when B is allowed to change even though it never
>>> should happen based up
On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger wrote:
>> In practical effect that is exactly what your proposal does. You just feel
>> better because you defined when B is allowed to change even though it never
>> should happen based upon our project policy. And any rare exception can
>> justi
On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger
wrote:
>
> > On Jun 20, 2016, at 8:53 AM, Mark Dilger
> wrote:
> >
> >
> > This is not a plea for keeping the three part versioning system. It's
> just
> > a plea not to have a 2 part versioning system masquerading as a three
> > part versioning sys
> On Jun 20, 2016, at 8:53 AM, Mark Dilger wrote:
>
>
> This is not a plea for keeping the three part versioning system. It's just
> a plea not to have a 2 part versioning system masquerading as a three
> part versioning system, or vice versa.
To clarify my concern, I never want to have to w
>
> In practical effect that is exactly what your proposal does. You just feel
> better because you defined when B is allowed to change even though it never
> should happen based upon our project policy. And any rare exception can
> justifiably be called a bug fix because, face it, it would o
On Monday, June 20, 2016, Mark Dilger wrote:
>
> > On Jun 18, 2016, at 5:48 PM, Josh Berkus > wrote:
> >
> > On 06/16/2016 11:01 PM, Craig Ringer wrote:
> >>
> >> I thought about raising this, but I think in the end it's replacing one
> >> confusing and weird versioning scheme for another confus
> On Jun 18, 2016, at 5:48 PM, Josh Berkus wrote:
>
> On 06/16/2016 11:01 PM, Craig Ringer wrote:
>>
>> I thought about raising this, but I think in the end it's replacing one
>> confusing and weird versioning scheme for another confusing and weird
>> versioning scheme.
>>
>> It does have the
On Sat, Jun 18, 2016 at 05:48:30PM -0700, Josh Berkus wrote:
> On 06/16/2016 11:01 PM, Craig Ringer wrote:
> >
> > I thought about raising this, but I think in the end it's replacing one
> > confusing and weird versioning scheme for another confusing and weird
> > versioning scheme.
> >
> > It do
On 06/16/2016 11:01 PM, Craig Ringer wrote:
>
> I thought about raising this, but I think in the end it's replacing one
> confusing and weird versioning scheme for another confusing and weird
> versioning scheme.
>
> It does have the advantage that that compare a two-part major like
> 090401 vs 0
On 06/17/2016 10:04 AM, Alvaro Herrera wrote:
> Merlin Moncure wrote:
>
>> Ugliness is a highly subjective qualifier. OTOH, Backwards
>> compatibility, at least when the checks are properly written :-), is a
>> very objective benefit.
>
> This is the argument that made us kept the PostgreSQL nam
On Fri, Jun 17, 2016 at 1:04 PM, Alvaro Herrera
wrote:
> Merlin Moncure wrote:
>
>> Ugliness is a highly subjective qualifier. OTOH, Backwards
>> compatibility, at least when the checks are properly written :-), is a
>> very objective benefit.
>
> This is the argument that made us kept the Postgr
Merlin Moncure wrote:
> Ugliness is a highly subjective qualifier. OTOH, Backwards
> compatibility, at least when the checks are properly written :-), is a
> very objective benefit.
This is the argument that made us kept the PostgreSQL name instead of
renaming back to Postgres. I'm not a fan of
On Fri, Jun 17, 2016 at 1:01 AM, Craig Ringer wrote:
> On 17 June 2016 at 08:34, Greg Stark wrote:
>>
>> So we would release 10.0.0 and 10.0.1 and the next major release would be
>> 11.0.0.
>>
>> This would have two benefits:
>>
>> 1) It emphasises that minor releases continue to be safe minor up
On Fri, Jun 17, 2016 at 2:01 AM, Craig Ringer wrote:
> On 17 June 2016 at 08:34, Greg Stark wrote:
>
>> So we would release 10.0.0 and 10.0.1 and the next major release would be
>> 11.0.0.
>>
>> This would have two benefits:
>>
>> 1) It emphasises that minor releases continue to be safe minor up
On 17 June 2016 at 08:34, Greg Stark wrote:
> So we would release 10.0.0 and 10.0.1 and the next major release would be
> 11.0.0.
>
> This would have two benefits:
>
> 1) It emphasises that minor releases continue to be safe minor updates
> that offer the same stability guarantees. Users would be
On 15 June 2016 at 06:48, David G. Johnston
wrote:
>
> We could stand to be more explicit here. The docs for version()
> indicated the server_version_num should be used for "machine processing".
>
> The implied correct way to access the canonical server version is thus:
>
> SELECT current_sett
On 15 Jun 2016 2:59 pm, "David G. Johnston"
wrote:
>
> IIRC the plan is to have the machine version behave as if the middle
number is present and always zero. It would be (the?) one place that the
historical behavior remains visible but it is impossible to have a totally
clean break.
I haven't b
On 6/15/16 9:04 AM, Merlin Moncure wrote:
We could stand to be more explicit here. The docs for version()
>> > indicated
>> > the server_version_num should be used for "machine processing".
On a somewhat related note, any objection to adding server_version_num
to pg_config? It's common to nee
On Wed, Jun 15, 2016 at 8:59 AM, David G. Johnston
wrote:
> On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure wrote:
>>
>> On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
>> wrote:
>> > On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure
>> > wrote:
>> >>
>> >> On Tue, Jun 14, 2016 at 4:13 PM, Jim
On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure wrote:
> On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
> wrote:
> > On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure
> wrote:
> >>
> >> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby
> >> wrote:
> >> > On 6/14/16 3:56 PM, Tom Lane wrote:
> >> >>
On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
wrote:
> On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure wrote:
>>
>> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby
>> wrote:
>> > On 6/14/16 3:56 PM, Tom Lane wrote:
>> >>
>> >> Jim Nasby writes:
>> >>>
>> >>> On 6/14/16 3:01 PM, Robert Haas wrot
On 06/14/2016 05:08 PM, Cat wrote:
We have the capability to provide (semi-)structured data. Might be an idea
to make greater use of it.
postgres=# SELECT * from
to_json(row(current_setting('server_version_num'))) as version;
Sincerely,
jD
--
Command Prompt, Inc. http:/
On 15/06/16 02:08, Cat wrote:
> is it possible to introduce a JSONB output to it.
No thanks.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On Tue, Jun 14, 2016 at 01:38:44PM -0700, Joshua D. Drake wrote:
> On 06/14/2016 12:46 PM, Jim Nasby wrote:
>
> >Any ideas on naming for such a function? version_detail()? I suppose
> >while we're at this we might as well provide the compile details as well.
>
> version(detail) or version(verbose
On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure wrote:
> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby
> wrote:
> > On 6/14/16 3:56 PM, Tom Lane wrote:
> >>
> >> Jim Nasby writes:
> >>>
> >>> On 6/14/16 3:01 PM, Robert Haas wrote:
>
> This seems kind of silly, because anybody who is writ
On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby wrote:
> On 6/14/16 3:56 PM, Tom Lane wrote:
>>
>> Jim Nasby writes:
>>>
>>> On 6/14/16 3:01 PM, Robert Haas wrote:
This seems kind of silly, because anybody who is writing code that
might have to run against an existing version of the dat
On 6/14/16 3:56 PM, Tom Lane wrote:
Jim Nasby writes:
On 6/14/16 3:01 PM, Robert Haas wrote:
This seems kind of silly, because anybody who is writing code that
might have to run against an existing version of the database won't be
able to use it. The one thing that absolutely has to be cross-
On 6/14/16 3:38 PM, Joshua D. Drake wrote:
On 06/14/2016 12:46 PM, Jim Nasby wrote:
Any ideas on naming for such a function? version_detail()? I suppose
while we're at this we might as well provide the compile details as well.
version(detail) or version(verbose)
I don't think that makes as
Jim Nasby writes:
> On 6/14/16 3:01 PM, Robert Haas wrote:
>> This seems kind of silly, because anybody who is writing code that
>> might have to run against an existing version of the database won't be
>> able to use it. The one thing that absolutely has to be cross-version
>> is the method of d
On 6/14/16 3:01 PM, Robert Haas wrote:
D) Add a version function to 10.0 that returns both parts separately.
>
> My vote is D. Parsing version() output is a wart, but coming out with a
> split output version of that in 9.6 that still has to support 3 numbers
> would also be a wart. We've lived wi
On 06/14/2016 12:46 PM, Jim Nasby wrote:
Any ideas on naming for such a function? version_detail()? I suppose
while we're at this we might as well provide the compile details as well.
version(detail) or version(verbose)
JD
--
Command Prompt, Inc. http://the.postgres.company/
On Tue, Jun 14, 2016 at 3:46 PM, Jim Nasby wrote:
> On 6/13/16 2:12 PM, Merlin Moncure wrote:
>>
>> A) make a variant of version() that returns major/minor/bugfix as
>> separate fields with minor being set to 0 for all released versions
>> 10.0 and beyond. We could then add a NOTE to the version
On 6/13/16 2:12 PM, Merlin Moncure wrote:
A) make a variant of version() that returns major/minor/bugfix as
separate fields with minor being set to 0 for all released versions
10.0 and beyond. We could then add a NOTE to the version function and
other places suggesting to use that instead for 9.
On Tue, May 17, 2016 at 12:45 AM, Craig Ringer wrote:
> On 14 May 2016 at 02:49, Tom Lane wrote:
>>
>> * This year's major release will be 9.6.0, with minor updates 9.6.1,
>> 9.6.2, etc. It's too late to do otherwise for this release cycle.
>>
>> * Next year's major release will be 10.0, with mi
On 17 May 2016 at 10:37, David Steele wrote:
> On 5/17/16 10:51 AM, David Fetter wrote:
>
>> On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:
>>> On 14 May 2016 at 02:49, Tom Lane wrote:
* This year's major release will be 9.6.0, with minor updates 9.6.1,
9.6.2, etc. It's
On 5/17/16 10:51 AM, David Fetter wrote:
> On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:
>> On 14 May 2016 at 02:49, Tom Lane wrote:
>>> * This year's major release will be 9.6.0, with minor updates 9.6.1,
>>> 9.6.2, etc. It's too late to do otherwise for this release cycle.
>>>
On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:
> On 14 May 2016 at 02:49, Tom Lane wrote:
> > * This year's major release will be 9.6.0, with minor updates 9.6.1,
> > 9.6.2, etc. It's too late to do otherwise for this release cycle.
> >
> > * Next year's major release will be 10.0,
On 14 May 2016 at 02:49, Tom Lane wrote:
>
> * This year's major release will be 9.6.0, with minor updates 9.6.1,
> 9.6.2, etc. It's too late to do otherwise for this release cycle.
>
> * Next year's major release will be 10.0, with minor updates 10.1,
> 10.2, etc.
>
> * The year after, 11.0.
On Sat, May 14, 2016 at 8:37 PM, Tom Lane wrote:
> Jeff Janes writes:
>> There are lots of improvement which get done to in-memory data
>> structures that wouldn't require a pg_dump/pg_upgrade, which could in
>> principle be ported into prior major versions if we had the resources
>> (reviewing,
Peter Eisentraut writes:
> On 5/16/16 9:53 AM, Greg Stark wrote:
>> I thought the idea was that Berkeley tossed an source tree over the
>> wall with no version number and then the first five releases were
>> Postgres95 0.x, Postgres95 1.0, Postgres95 1.0.1, Postgres95 1.0.2,
>> Postgres95 1.0.9. T
On 5/16/16 9:53 AM, Greg Stark wrote:
On Sat, May 14, 2016 at 1:00 AM, Tom Lane wrote:
If that were the standard, we'd never have bumped the major version at
all, and would still be on 4.something (or whatever Berkeley was using
when they tossed it over the wall; I'm not too clear on whether t
On Sat, May 14, 2016 at 1:00 AM, Tom Lane wrote:
> If that were the standard, we'd never have bumped the major version at
> all, and would still be on 4.something (or whatever Berkeley was using
> when they tossed it over the wall; I'm not too clear on whether there was
> ever a 5.x release).
I
On 5/13/16 5:01 PM, Tom Lane wrote:
If we do decide to change the numbering strategy, there are quite a
few small details that probably ought to be fixed while we're at it.
I think it'd be a good idea to start separating "devel" or "betaN"
with a dot, for instance, like "10.devel" not "10devel".
On 15/05/16 14:42, Magnus Hagander wrote:
On Sun, May 15, 2016 at 2:29 PM, Álvaro Hernández Tortosa
mailto:a...@8kdata.com>> wrote:
On 14/05/16 20:02, Petr Jelinek wrote:
+1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.
It will hopefully both end these dis
On Sun, May 15, 2016 at 2:29 PM, Álvaro Hernández Tortosa
wrote:
>
>
> On 14/05/16 20:02, Petr Jelinek wrote:
>
>> +1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.
>>
>> It will hopefully both end these discussions and remove the confusion the
>> current versioning scheme has (I too hea
On 14/05/16 20:02, Petr Jelinek wrote:
+1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.
It will hopefully both end these discussions and remove the confusion
the current versioning scheme has (I too heard way to many times about
people using postgres8 or postgres9).
Even wors
On Sun, May 15, 2016 at 11:59 AM, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>> I think moving to a two-number format is a mistake: what exactly will
>> PQserverVersion() return in that case?
>
> For, say, 10.2 it would be 12, equivalent to 10.0.2 under old style.
>
> We could redefine i
Jeff Janes writes:
> There are lots of improvement which get done to in-memory data
> structures that wouldn't require a pg_dump/pg_upgrade, which could in
> principle be ported into prior major versions if we had the resources
> (reviewing, testing, packaging) to do it, with an increase in the
>
On Sat, May 14, 2016 at 7:51 PM, Greg Sabino Mullane wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
>> Wasn't there some controversy about switching to major.minor versioning
>> this in -advocacy?
>>
>> http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5...@bigl
"Greg Sabino Mullane" writes:
> I think moving to a two-number format is a mistake: what exactly will
> PQserverVersion() return in that case?
For, say, 10.2 it would be 12, equivalent to 10.0.2 under old style.
We could redefine it as being major plus four-digit minor, really.
Under the cu
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Wasn't there some controversy about switching to major.minor versioning
> this in -advocacy?
>
> http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5...@biglumber.com
I proposed in that thread that we always increment the first
On 05/13/2016 07:18 PM, Mark Dilger wrote:
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence. It therefore makes sense to
> reserve room in the numbering scheme to be clear and honest about when
> backwards compatibility has been
On Fri, May 13, 2016 at 08:55:20PM -0400, David G. Johnston wrote:
> The opinion seems to be that major.0 is some kind of magic incantation in
> the broader world of users...
>From my reading of the thread, while certainly that is the general
definition of a .0, having infrequent .0 releases is no
On Fri, May 13, 2016 at 05:31:00PM -0400, David G. Johnston wrote:
> The underlying premise, for me, of choosing .4 or .5 was that presently we
> discontinue support after 5 years/releases. A new .0 would come out just
> as we discontinue the previous .0
Well maybe the 5 year support cycle would
+1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.
It will hopefully both end these discussions and remove the confusion
the current versioning scheme has (I too heard way to many times about
people using postgres8 or postgres9).
For those saying this is version inflation. I don't see
El 13/05/16 a las 15:36, Josh berkus escribió:
> On 05/13/2016 11:31 AM, Alvaro Herrera wrote:
>> Josh berkus wrote:
>>
>>> Anyway, can we come up with a consensus of some minimum changes it will
>>> take to make the next version 10.0?
>>
>> I think the next version should be 10.0 no matter what
El 13/05/16 a las 15:31, Alvaro Herrera escribió:
> Josh berkus wrote:
>
>> Anyway, can we come up with a consensus of some minimum changes it will
>> take to make the next version 10.0?
>
> I think the next version should be 10.0 no matter what changes we put
> in.
+1
And another +1 on Tom's
On 05/14/2016 07:08 AM, Robert Haas wrote:
On Fri, May 13, 2016 at 8:00 PM, Tom Lane wrote:
Any project that starts inflating its numbering scheme sends a message to
users of the form, "hey, we've just been taken over by marketing people, and
software quality will go down from now on."
I don'
On Fri, May 13, 2016 at 11:39 AM, Tom Lane wrote:
> Robert Haas writes:
>> There is a long-running thread on pgsql-hackers on whether 9.6 should
>> instead be called 10.0.
>
> First I've seen it mentioned here.
>
> I think you are just about exactly one week too late to bring this up.
> Once we'v
On Fri, May 13, 2016 at 8:00 PM, Tom Lane wrote:
>> Any project that starts inflating its numbering scheme sends a message to
>> users of the form, "hey, we've just been taken over by marketing people, and
>> software quality will go down from now on."
>
> I don't think this is about version numbe
Re: Álvaro Hernández Tortosa 2016-05-14 <5736f966.3040...@8kdata.com>
> Having said that, I believe having a single major number is a more
> effective marketing. Non major-major versions may make the release look like
> a "probably not worth" upgrade. People may hold their breath until a
> majo
On 14/05/16 02:00, Tom Lane wrote:
[...]
I don't think this is about version number inflation, but actually more
the opposite. What you're calling the major number is really a marketing
number. There is not a technical distinction between major releases where
we choose to bump the first numb
> On May 13, 2016, at 8:26 PM, David G. Johnston
> wrote:
>
> On Fri, May 13, 2016 at 10:18 PM, Mark Dilger wrote:
>
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence.
>
> You started this sub-thread with:
>
> "If I unde
On Fri, May 13, 2016 at 10:18 PM, Mark Dilger
wrote:
>
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence.
You started this sub-thread with:
"If I understand correctly..."
I'm not sure that you do...
Our scheme is, in you
> On May 13, 2016, at 6:33 PM, David G. Johnston
> wrote:
>
> On Fri, May 13, 2016 at 7:32 PM, Mark Dilger wrote:
>
> Any project that starts inflating its numbering scheme sends a message to
> users of the form, "hey, we've just been taken over by marketing people, and
> software quality wil
On Fri, May 13, 2016 at 7:32 PM, Mark Dilger
wrote:
>
> Any project that starts inflating its numbering scheme sends a message to
> users of the form, "hey, we've just been taken over by marketing people,
> and
> software quality will go down from now on."
>
Tom brought up my own thoughts on th
> On May 13, 2016, at 5:49 PM, Josh berkus wrote:
>
> On 05/13/2016 05:22 PM, Mark Dilger wrote:
>> Any project that starts inflating its numbering scheme sends a message to
>> users of the form, "hey, we've just been taken over by marketing people,
>> and
>> software quality wi
On Fri, May 13, 2016 at 6:44 PM, Michael Banck wrote:
> On Fri, May 13, 2016 at 05:31:00PM -0400, David G. Johnston wrote:
> > The underlying premise, for me, of choosing .4 or .5 was that presently
> we
> > discontinue support after 5 years/releases. A new .0 would come out just
> > as we disc
On 05/13/2016 05:22 PM, Mark Dilger wrote:
>>> >> Any project that starts inflating its numbering scheme sends a message to
>>> >> users of the form, "hey, we've just been taken over by marketing people,
>>> >> and
>>> >> software quality will go down from now on."
>> >
>> > I don't think this is
> On May 13, 2016, at 5:00 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> A major number change should indicate that something even bigger than on-disk
>> compatibility has changed, such as a change that precludes even a dump and
>> restore from working, or that breaks network communication pro
Mark Dilger writes:
> A major number change should indicate that something even bigger than on-disk
> compatibility has changed, such as a change that precludes even a dump and
> restore from working, or that breaks network communication protocols, etc.
If that were the standard, we'd never have
1 - 100 of 163 matches
Mail list logo
