Re: [HACKERS] 10.0
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 -- apparently not? It was stated somewhere in these threads that the problem with the Firefox scheme is that they release new versions every six weeks, so naturally there is enormous version number inflation. In our case we would still release new versions once a year, so by 2026 (ten years from now) we would be releasing Postgres 19 while Firefox will be in version 133. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 does have the advantage that that compare a two-part major like 090401 vs 090402 won't be confused when they compare 100100 and 100200, since it'll be 11 and 12. So it's more backward-compatible. But ugly. Realistically, though, we're more likely to end up with 10.0.1 than 10.1. I don't think we're anywhere near plumbing the depths of the stuff which will break because folks are parsing our version numbers with regexes. In more major software, this will break nagios check_postgres. Having a 3 part versioning scheme where the middle portion is always zero makes the least sense to me of any of the proposals. If we're going to have the pain and hurting of moving to a 2 part versioning scheme, and breaking nagios and what not, then lets just get on with it. If we're going to keep all three parts, can we please use my proposal earlier in this thread where A.B.C are allocated for: C++: bug fixes only B++: new features added, but still backward compatible with prior version A++: new features added, not backward compatible, pg_upgrade required If every new feature release ends up requiring pg_upgrade, then B will always be zero, which is no worse than your proposal. But at least users can refer to part B to learn something useful, namely whether they will need to run pg_upgrade as part of upgrading their existing cluster. This has the advantage that new minor features, like adding a new guc, can be released sooner than the next major release, but does not have to be released in disguise as if it were a bug fix. 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. mark I agree with this! 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! Cheers, Gavin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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) debating this, I felt the need to add yet another possibility ... (/me dons some asbestos underwear) next version: 100100 [server_version] will be (gasp!) 10g R1 (for marketing people) or simply 10.1.0 for the rest of the world. Next update would be 1001001, a.k.a. 10g R1 u1 i.e. we would skip 10.0 alltogether, preserving everybody's sanity in the process. IMV, 10g R1 uX should plainly be a different *major* release than 10g R2 uY and hence requiring a proper "migration" (i.e. pg_upgrade) ...or at least that's what several multi-billion software companies have taught most everybody to believe :$ 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 bumping the first digit (e.g. every 5 years like clockwork). That's another story Either 5 (for historical reasons) or 10 year (sounds good) ... or whenever it makes sense! (such as when a multi-modal, hybrid row+column, vectored, MPP, super-duper-distributed, automagically self-scaling or the like release is ready) Thanks, / J.L. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 to stick with the current >>> three-part versioning scheme, possibly with some change to the >>> algorithm for bumping the first digit (e.g. every 5 years like >>> clockwork). >> >> 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 this approach initially too, and I think it has merit -- > notably, that it would stop this discussion. It was said that moving > to two-part numbers would stop all discussion, but it seems to have had > exactly the opposite effect. If voting is still possible, then I agree: no changes please! It won't make things easier to have a 10g or a 10.8 to explain, instead of a 10.0.8... and I'm not sure it'll make things easier to not have the chance to bump the 2 major parts if it happened to be interesting in the future like it was for 7.4->8 and 8.4->9 (9 is «new», it's the first time we go over .4 to bump first digit, but it's also the first time we have found a way to shorten release cycle) -- -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 release > prior to 9.6 deserved to be called 10.0? Maybe somebody suggested > that for 9.2 and it generated, like, four emails? I certainly don't > remember any discussion that remotely approached the amount of time > we've spent litigating both the version number and the version > numbering scheme in the last few months. I do think Robert is 100% accurate on this. Personally, I have never understood the reduce arguments reason, and the jump to 8.0 and 9.0 were done in a positive way that I think provided value to our community. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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, Postgres95 1.0, Postgres95 1.0.1, Postgres95 1.0.2, > >> Postgres95 1.0.9. Then the idea was that PostgreSQL 6.0 was the sixth > >> major release counting those as the first five releases. > > > The last release out of Berkeley was 4.2. > > Correct --- I have a copy of that tarball. > > > Then Postgres95 was "5", and then PostgreSQL started at 6. > > I wasn't actually around at the time, but our commit history starts > with this: > > Author: Marc G. Fournier > Branch: master Release: REL6_1 [d31084e9d] 1996-07-09 06:22:35 + > > Postgres95 1.01 Distribution - Virgin Sources > > The first mention of 6.anything is here: > > Author: Bruce Momjian > Branch: master Release: REL6_1 [a2b7f6297] 1996-12-28 02:01:58 + > > Updated changes for 6.0. > > I see no references in the commit history to 5.anything, but there > are some references like this: The sole reason we jumped from Postgres 1.09 to 6.0 was that in Postgres 1.0.X, $PGDATA/PG_VERSION contained '5', meaning when Berkeley went from University Postgres 4.2 to Postgres95 1.0, they didn't reset PG_VERSION. We really had no way of going to Postgres 2.0 unless we were prepared to have data/PG_VERSION never match the major version number. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 have > played out a bit differently...maybe. In any case 9.6 was a foregone > conclusion given -advocacy's timeline and because of its independence from > -hackers (Tom, the tagger, specifically). One thing to keep in mind is that I did not realize there was any urgency to make the decision before beta1, because Tom had previous made reference to renumbering this version to 10.0 *over the summer* depending on how awesome we then thought parallel query was. I assumed that he would not have made this comment if he had an objection to renumbering the release after beta1. Surely he didn't think we were going to do beta1 in the fall. It was only after beta1 had been released that anyone said post-beta1 was too late. Had that been brought up earlier, the discussion might have gone differently, too. Also, it is not the case that because Tom applies the tag, he also gets veto power over the version numbering scheme. That's not how decision-making in this community works. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 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 have played out a bit differently...maybe. In any case 9.6 was a foregone conclusion given -advocacy's timeline and because of its independence from -hackers (Tom, the tagger, specifically). but as soon as the discussion came over to > pgsql-hackers nothing would do but that we relitigate the whole thing > ignoring the previous discussion because it wasn't on pgsql-hackers. > Why -hackers is the right place to decide on the marketing version > number rather than -advocacy went unexplained, of course. I had the same thought. Yet no one even tried to move the discussion back there. And at this point PGCon was so close that I personally figured it would be discussed. It was, and an announcement was made that a decision was reached. No one voiced an objection so those not at PGCon (or at I) figured for better or worse we're going to version 10 (expected) and to address the expressed desire reduce the public confusion surrounding our major-major-minor version scheme we would instead switch to a more traditional major-minor scheme (acceptable). Now we have > a new consensus, at least the third if not the fourth or fifth, about > what to do on this topic, and since Tom likes this outcome better he'd > like to stop discussion right here. This portion of the thread was mostly a technical concern - how do we display the version in human-readable and machine-readable formats. I'd agree with your earlier idea that if you really want to open up the decision between 10.n.x and 10.x start a new thread on -advocacy. Tally up those at PGCon as a starting point and lets other toss in their lot from there. At this point I'm only seeing rehashing of the same arguments. Let other people make their, informed or otherwise, opinions known if you feel that the group at PGCon is not a fair sampling. > A two-part version numbering > scheme may or may not be for the best, but the idea that we're making > that decision in any principled way, or that the consensus on this new > system is any more valid than any of the previous consensus, doesn't > ring true to me. The idea that this discussion is not fixing any real > problem, though -- that rings true. > > You've hijack the meaning of "this here. Most of "this" thread ended up explaining the difference between "version()" and current_setting('server_version_num"). That needs to be addressed unless we revert back to status-quo. That isn't this thread, though. This thread assumes we are going to 10.0 and semantically losing the middle digit. I'd find it odd to argue against 10.0 on the basis that we'd be displaying 10.0.x in the output of version(). That seems like such a inconsequential detail in the larger scheme of things. Either you accept 10.0 and we pick a human readable output or you don't and the decision doesn't come into play. I'm happy with how things are (+0.5 for we should output 10.0.x for version()) so I'm stopping here. David J.
Re: [HACKERS] 10.0
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. The idea that this discussion is not fixing any real problem, though -- that rings true. sure -- it's my fault for starting the conversation back up. I was wondering about supporting older version checks, but only because I was unaware of the 'machine' variant of the version check (server_version_num), which properly supports numerical ordering for historical versions. If there's anything to do here, maybe we ought to document that server_version_num should be used for checking version a little more strongly. Judging by google searching, this is as not widely known as it should be. I certainly had no idea it even existed until you displayed the query. I have always used version() but then, I am not a -hacker. Sincerely, JD merlin -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 not fixing any real > problem, though -- that rings true. sure -- it's my fault for starting the conversation back up. I was wondering about supporting older version checks, but only because I was unaware of the 'machine' variant of the version check (server_version_num), which properly supports numerical ordering for historical versions. If there's anything to do here, maybe we ought to document that server_version_num should be used for checking version a little more strongly. Judging by google searching, this is as not widely known as it should be. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 that for 9.2 and it generated, like, four emails? I certainly don't remember any discussion that remotely approached the amount of time we've spent litigating both the version number and the version numbering scheme in the last few months. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 then later we had a revised consensus to retitle it to 10.0, but as soon as the discussion came over to pgsql-hackers nothing would do but that we relitigate the whole thing ignoring the previous discussion because it wasn't on pgsql-hackers. Why -hackers is the right place to decide on the marketing version number rather than -advocacy went unexplained, of course. Now we have a new consensus, at least the third if not the fourth or fifth, about what to do on this topic, and since Tom likes this outcome better he'd like to stop discussion right here. A two-part version numbering scheme may or may not be for the best, but the idea that we're making that decision in any principled way, or that the consensus on this new system is any more valid than any of the previous consensus, doesn't ring true to me. The idea that this discussion is not fixing any real problem, though -- that rings true. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 this approach initially too, and I think it has merit -- > notably, that it would stop this discussion. It was said that moving > to two-part numbers would stop all discussion, but it seems to have had > exactly the opposite effect. No, the argument for it was that we'd no longer have to have the annual discussions about "is it 10.0 yet?". There was no claim that getting there would be uncontroversial, only that things would be quieter once we did get there. Considering that same long-term viewpoint, I'm not very happy about the idea of "let's reserve the middle digit for compatible feature backports", because the minute we set up a numbering system like that, everybody and his brother will be arguing for making a branch on which to backport their favorite more-or-less-compatible new feature. You as well as others pointed out that we don't have the manpower to actually support any such thing ... so let's not open the door to it. If we do arrive at a consensus that going to simply "10.0, 10.1, etc" would be too much change, then I'd be in favor of adopting the every-ten-year rule instead, in hopes that we can at least shut down future "is it 10.0 yet" threads more quickly. But that really does nothing at all to fix the confusion so often shown by outsiders about the significance of our version numbers. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 current >> three-part versioning scheme, possibly with some change to the >> algorithm for bumping the first digit (e.g. every 5 years like >> clockwork). > > 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. Either there's a meaningful difference between the first > and second parts of the number, or there is not. If there is not, why > have separate parts? It can only cause confusion ... as this whole > thread, and its many many predecessors, amply illustrate. That's not how I remember it. At the Ottawa developer meeting, there were more votes for changing to a two-part versioning scheme than there were for retaining a three-part versioning scheme, but my recollection not overwhelmingly so. I'm pretty sure it was less than a 2/3 majority in favor of changing. Furthermore, essentially everyone in the room, including people who wanted to stick with a three-part scheme, was in favor of the next version's first component being 10. I do not recall there being a strong consensus among the people who wanted the next version to be 10.0.0 on how to decide when to go to 11.0.0, though. Various proposals were offered and most of them got no more than one vote. But saying that nobody other than me thought we should stick with a three-part scheme is revisionist history. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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, Robert, you already made your case for that approach and nobody else cared for it. I voted for this approach initially too, and I think it has merit -- notably, that it would stop this discussion. It was said that moving to two-part numbers would stop all discussion, but it seems to have had exactly the opposite effect. 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. Put that in the FAQ and wave at it like we do with hints ala Oracle. It is obvious from this thread alone that there is really no consensus. Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 versioning scheme, possibly with some change to the > > algorithm for bumping the first digit (e.g. every 5 years like > > clockwork). > > 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 this approach initially too, and I think it has merit -- notably, that it would stop this discussion. It was said that moving to two-part numbers would stop all discussion, but it seems to have had exactly the opposite effect. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 versioning scheme, possibly with some change to the > algorithm for bumping the first digit (e.g. every 5 years like > clockwork). > > I was speaking for the project/community as a distinct entity and not about any individual contributor. I'm acting as if we're past the point of individual opinions and votes on the decision to go to a two-part versioning scheme. We will still welcome any major revelations that may have gone unconsidered during the decision making but I find that to be unlikely. David J.
Re: [HACKERS] 10.0
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 some change to the > algorithm for bumping the first digit (e.g. every 5 years like > clockwork). 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. Either there's a meaningful difference between the first and second parts of the number, or there is not. If there is not, why have separate parts? It can only cause confusion ... as this whole thread, and its many many predecessors, amply illustrate. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 bumping the first digit (e.g. every 5 years like clockwork). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
> 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 the human form is not influenced by the fact the machine form > > has 6 digits (with leading zeros which the human form elides...). > > I don't have a problem with it if humans always use a two part number. I > don't read > the number 14 as being three parts, nor as being two parts, so it doesn't > matter. > What got me to respond this morning was Josh's comment: > > "Realistically, though, we're more likely to end up with 10.0.1 than 10.1." > > He didn't say "11 than 10.1", he said "10.0.1 than 10.1", which showed > that we > already have a confusion waiting to happen. > > Now, you can try to avoid the confusion by saying that we'll always use all > three > digits of the number rather than just two, or always use two digits rather > than three. > But how do you enforce that? > > You do realize he was referring to machine generated output here? No I don't, nor will anyone who finds that via a google search. That's my point. You core hackers feel perfectly comfortable with that because you understand what you are talking about. Hardly anybody else will. As you suggest, that's my $0.02, and I'm moving on. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 digits (with leading zeros which the human form > elides...). > > I don't have a problem with it if humans always use a two part number. I > don't read > the number 14 as being three parts, nor as being two parts, so it > doesn't matter. > What got me to respond this morning was Josh's comment: > > "Realistically, though, we're more likely to end up with 10.0.1 than 10.1." > > He didn't say "11 than 10.1", he said "10.0.1 than 10.1", which showed > that we > already have a confusion waiting to happen. > > Now, you can try to avoid the confusion by saying that we'll always use > all three > digits of the number rather than just two, or always use two digits rather > than three. > But how do you enforce that? You do realize he was referring to machine generated output here? That means unless we get careless we have full control over what is output. Enforcement is easy. If in some sense the middle number exists, but is > always zero, then some people will mention it and some won't, with the > result that > 10.0.x and 10.x will be used by different people at different times to > refer to the same > release. > Back to human generated output again... > > The problem that Tom and others mentioned upthread (rather a while ago) is > that > up until now, we've had three digits in the version numbers, but the first > two numbers > really just mean one thing, "major", and the last number means "minor". > IIUC, he > wanted to stop using two separate digits where clearly just one would > suffice. Hence > the proposal to go to things like 10.0, 10.1. But others chimed in saying > that we need > to keep it three parts for compatibility reasons, so how about we just > have the middle > number always be zero. My response to that is what I've just said. You > can't do that > without creating ambiguity in future version numbers, because of how > people use > language. If you want to avoid the ambiguity and confusion going forward, > all the > numbers in the scheme must have meaning and not be mere placeholders. I > gave a > suggestion about what the middle number *could* mean, which I don't deny > is what > I'd like best, but it's just a suggestion to avoid the confusion inherent > in people eliding > the middle number sometimes but not other times. > > Given everything else you wrote I find it hard to believe you actually, deep down, think that "definitional meaning " is sufficient here. The reason informed people say "9.2.x" and "9.3.x" is that those are in fact t w o different things where the middle number changes every year. If we go right from: 10.0.7 to 11.0.0 there will be no added value in distinguishing between 10.0.x and 10.x and so people will no t do it - and and you said there is no way to force them. That the middle number could, in well defined circumstances, change is immaterial when it will not do so in practice. So, we can ensure the machine output is consistent. Th at is easy. The only question here is whether we make the machine human-readable output better conform to expected human-generate usage (i.e., 10.x) or do we keep the machine generated human-readable output compatible with the existing format so that machine processing of the string is unaffected. The only way to address your concern is to continue with the status-quo. Make 10.1.x and 10.2.x and so people cannot meaningfully drop the second digit. Since it has been accepted that the status quo has its own problems - namely that the less informed population are already treating our version number as if it is 9.x (instead of 9.5.x) that change to better conform to societal expectations is desirable. If you're going to vote for status-quo I'd say add your $0.02 and move on; I don't think that is still on the table (unless some real bad reality smacks us in the face. The human generated dynamic is thus a foregone conclusion - the majority are going to call and write our next release as 10.x. The machine readable output will be 10. The human readable output seems to be up for a vote. 10.0.x or 10.x 10.x is the desired output. Having a list of actual problems likely to face our users if we do this would be helpful. Identifying exactly where this human-readable output string appears would be helpful. Obviously the "version()" command but where else? I do think Josh has the right of it, though. Humans seeing 10.0.4 in the version() output will easily adapt once they understand why we left it that way. Machines cannot adapt as readily. The fact that we advertise 10.4 while our version number is 10.0.4 in one small corner of out system is a minor irritant compared to the potential for
Re: [HACKERS] 10.0
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) time this has come up during this discussion - the last being 20 emails and 3 days ago. In short, we don't and never will be semver compliant so if anything its numbering protocol is something to avoid, not embrace. David J.
Re: [HACKERS] 10.0
> 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 don't quite > >>> understand what it is. > >> > >> I do, indeed, and here it is: > >> > >> 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 alert > >> users that you've not just back ported a bug fix, but a feature. Any new > >> features that are not compatible don't get back ported. > >> > >> If you fix a bug on master during development, you can back port that > >> as well. But instead of bumping the middle number, you bump the last > >> number. > >> > >> Somebody running a version that is three major versions back could > >> still get the advantage of new features, so long as those new features > >> are not incompatible. It's frequently not nearly so easy to run pg_upgrade > >> as it is to run rpm -U. You get downtime either way, but the elapsed > >> time of that downtime is orders of magnitude different. > >> > >> Someone else running that same version from three major versions ago > >> can take a more conservative policy, and only upgrade bug fixes, and > >> forego the back ported features. > >> > >> You still have one major version release per year. At that time, you can > >> also release back-port versions of prior major versions. > > > > OFFLIST: > > > > You are fighting a losing if noble battle. > > I think all my emails on this subject have been seriously misunderstood. > Perhaps the problem is that I don't understand some critical issue. Can > you please help me understand this part: > > It seems like people want releases, starting with 10.0, to be named things > like 10.0, 10.1, 10.2,..., but for the purposes of communicating with programs > like nagios refer to them as 10.0.0, 10.0.1, 10.0.2 > > Is that right? > > That's the part that really annoys me, and I keep trying to argue for not > doing > that, and people keep replying to other parts of my messages rather than > replying to the core part of what I am saying. > > Why would any sensible person want a release to sometimes be called > "10.4", but the exact same release sometimes referred to as "10.0.4"? > This is just going to confuse average software users, as they would never > expect that 10.4 and 10.0.4 are the same thing. > > Have I misunderstood what is being proposed? > > The software is only ever going to report 10.0.4 OR 10.4. The area of > concern is that people are going to get annoyed at saying: "that was fixed in > 10.0.4" and so mailing lists and other forums where people write the numbers > instead of a computer are going to be littered with: "that was fixed in 10.4". > > So now human speak and machine speak are disjointed. > > The machine form output for that release is going to be 14 regardless of > the decision to make the human form 10.4 or 10.0.4 > > 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 digits (with leading zeros which the human form elides...). I don't have a problem with it if humans always use a two part number. I don't read the number 14 as being three parts, nor as being two parts, so it doesn't matter. What got me to respond this morning was Josh's comment: "Realistically, though, we're more likely to end up with 10.0.1 than 10.1." He didn't say "11 than 10.1", he said "10.0.1 than 10.1", which showed that we already have a confusion waiting to happen. Now, you can try to avoid the confusion by saying that we'll always use all three digits of the number rather than just two, or always use two digits rather than three. But how do you enforce that? If in some sense the middle number exists, but is always zero, then some people will mention it and some won't, with the result that 10.0.x and 10.x will be used by different people at different times to refer to the same release. The problem that Tom and others mentioned upthread (rather a while ago) is that up until now, we've had three digits in the version numbers, but the first two numbers really just mean one thing, "major", and the last number means "minor". IIUC, he wanted to stop using two separate digits where clearly just one would suffice. Hence the proposal to go to things like 10.0, 10.1. But others chimed in saying that we need to keep it three parts for compatibility reasons, so how about we just have the middle number always be zero. My response to that is what I've just sai
Re: [HACKERS] 10.0
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 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 here it is: >> >> >> >> 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 alert >> >> users that you've not just back ported a bug fix, but a feature. Any >> new >> >> features that are not compatible don't get back ported. >> >> >> >> If you fix a bug on master during development, you can back port that >> >> as well. But instead of bumping the middle number, you bump the last >> >> number. >> >> >> >> Somebody running a version that is three major versions back could >> >> still get the advantage of new features, so long as those new features >> >> are not incompatible. It's frequently not nearly so easy to run >> pg_upgrade >> >> as it is to run rpm -U. You get downtime either way, but the elapsed >> >> time of that downtime is orders of magnitude different. >> >> >> >> Someone else running that same version from three major versions ago >> >> can take a more conservative policy, and only upgrade bug fixes, and >> >> forego the back ported features. >> >> >> >> You still have one major version release per year. At that time, you >> can >> >> also release back-port versions of prior major versions. >> > >> > OFFLIST: >> > >> > You are fighting a losing if noble battle. >> >> I think all my emails on this subject have been seriously misunderstood. >> Perhaps the problem is that I don't understand some critical issue. Can >> you please help me understand this part: >> >> It seems like people want releases, starting with 10.0, to be named things >> like 10.0, 10.1, 10.2,..., but for the purposes of communicating with >> programs >> like nagios refer to them as 10.0.0, 10.0.1, 10.0.2 >> >> Is that right? >> >> That's the part that really annoys me, and I keep trying to argue for not >> doing >> that, and people keep replying to other parts of my messages rather than >> replying to the core part of what I am saying. >> >> Why would any sensible person want a release to sometimes be called >> "10.4", but the exact same release sometimes referred to as "10.0.4"? >> This is just going to confuse average software users, as they would never >> expect that 10.4 and 10.0.4 are the same thing. >> >> Have I misunderstood what is being proposed? >> > > The software is only ever going to report 10.0.4 OR 10.4. The area of > concern is that people are going to get annoyed at saying: "that was fixed > in 10.0.4" and so mailing lists and other forums where people write the > numbers instead of a computer are going to be littered with: "that was > fixed in 10.4". > > So now human speak and machine speak are disjointed. > > The machine form output for that release is going to be 14 regardless > of the decision to make the human form 10.4 or 10.0.4 > > 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 digits (with leading zeros which the human form elides...). > > This thread started with complaint that people are parsing our human form > output instead of the machine form. The OP later admitted that he didn't > realize that a machine form was so readily available. That is worry-some, > since I doubt that is an isolated incident, and leads to the discussion of > what form the human intended version should take. > > David J. > >
Re: [HACKERS] 10.0
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 here it is: > >> > >> 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 alert > >> users that you've not just back ported a bug fix, but a feature. Any > new > >> features that are not compatible don't get back ported. > >> > >> If you fix a bug on master during development, you can back port that > >> as well. But instead of bumping the middle number, you bump the last > >> number. > >> > >> Somebody running a version that is three major versions back could > >> still get the advantage of new features, so long as those new features > >> are not incompatible. It's frequently not nearly so easy to run > pg_upgrade > >> as it is to run rpm -U. You get downtime either way, but the elapsed > >> time of that downtime is orders of magnitude different. > >> > >> Someone else running that same version from three major versions ago > >> can take a more conservative policy, and only upgrade bug fixes, and > >> forego the back ported features. > >> > >> You still have one major version release per year. At that time, you > can > >> also release back-port versions of prior major versions. > > > > OFFLIST: > > > > You are fighting a losing if noble battle. > > I think all my emails on this subject have been seriously misunderstood. > Perhaps the problem is that I don't understand some critical issue. Can > you please help me understand this part: > > It seems like people want releases, starting with 10.0, to be named things > like 10.0, 10.1, 10.2,..., but for the purposes of communicating with > programs > like nagios refer to them as 10.0.0, 10.0.1, 10.0.2 > > Is that right? > > That's the part that really annoys me, and I keep trying to argue for not > doing > that, and people keep replying to other parts of my messages rather than > replying to the core part of what I am saying. > > Why would any sensible person want a release to sometimes be called > "10.4", but the exact same release sometimes referred to as "10.0.4"? > This is just going to confuse average software users, as they would never > expect that 10.4 and 10.0.4 are the same thing. > > Have I misunderstood what is being proposed? > The software is only ever going to report 10.0.4 OR 10.4. The area of concern is that people are going to get annoyed at saying: "that was fixed in 10.0.4" and so mailing lists and other forums where people write the numbers instead of a computer are going to be littered with: "that was fixed in 10.4". So now human speak and machine speak are disjointed. The machine form output for that release is going to be 14 regardless of the decision to make the human form 10.4 or 10.0.4 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 digits (with leading zeros which the human form elides...). This thread started with complaint that people are parsing our human form output instead of the machine form. The OP later admitted that he didn't realize that a machine form was so readily available. That is worry-some, since I doubt that is an isolated incident, and leads to the discussion of what form the human intended version should take. David J.
Re: [HACKERS] 10.0
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 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 write code like this: > > > > CASE WHEN pg_version eq '11.1' OR pg_version eq '11.0.1' THEN > foo() > >WHEN pg_version eq '11.2' OR pg_version eq '11.0.2' > THEN bar() > > > > or > > > > if (0 == strcmp(pg_version_string, "11.1") || 0 == > strcmp(pg_version_string, "11.0.1")) > > foo(); > > else if (0 == strcmp(pg_version_string, "11.2") || 0 == > strcmp(pg_version_string, "11.0.2")) > > bar(); > > > > either in sql, perl, c, java, or anywhere else. As soon as you have two > different > > formats for the version string, you get into this hell. Yeah, ok, you > may have > > a sql level function for this, but I'm thinking about applications > somewhat removed > > from a direct connection to the database, where you can't be sure which > format > > you'll be handed. > > > > Now you argue for keeping the middle number on pure compatibility > grounds... > > I am not arguing for that. I'm arguing against having two different > versions of the > same thing. If you go with a two part versioning scheme that is sometimes > written as a > three part versioning scheme, you make every bit of code that deals with > it from now on > have to deal with both possible versions in order to be robust. > > My preference is to have a three part versioning scheme where all three > parts have > different purposes. But since the community seems to have no interest in > that, and > have largely (if not universally) rejected that idea, I'm falling back to > merely arguing > that if we're going to have a two part versioning system, we should do > that everywhere, > and if we can't do that everywhere, then we should do that nowhere. > > You appear to be arguing that we should have a versioning scheme that is > sometimes > two parts, and sometimes three parts, but when three parts, always make > the middle > number zero. The part of that which bothers me most is not the "always > zero" part. It's > the "sometimes two parts, sometimes three parts" part > The machine representation of the version number is 6 digits without any punctuation. The human representation for version numbers >= 10 is two integers separated using a full-stop/period/decimal "." You would never write 10.0.2 instead of 10.2 just like you'd never write 1002 instead of 12 You only have to do more than one thing if you are using the wrong representation and are trying to be robust. While I understand that some people may indeed be doing that or otherwise stuck in that unfortunate circumstance accommodating their needs amounts to nothing other than maintaining compatibility for unsupported usage. I'll admit we probably could have been more explicit on what we do consider proper usage - which is why I have at least some sympathy for the position. David J.
Re: [HACKERS] 10.0
> 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 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 alert >> users that you've not just back ported a bug fix, but a feature. Any new >> features that are not compatible don't get back ported. >> >> If you fix a bug on master during development, you can back port that >> as well. But instead of bumping the middle number, you bump the last >> number. >> >> Somebody running a version that is three major versions back could >> still get the advantage of new features, so long as those new features >> are not incompatible. It's frequently not nearly so easy to run pg_upgrade >> as it is to run rpm -U. You get downtime either way, but the elapsed >> time of that downtime is orders of magnitude different. >> >> Someone else running that same version from three major versions ago >> can take a more conservative policy, and only upgrade bug fixes, and >> forego the back ported features. >> >> You still have one major version release per year. At that time, you can >> also release back-port versions of prior major versions. > > OFFLIST: > > You are fighting a losing if noble battle. I think all my emails on this subject have been seriously misunderstood. Perhaps the problem is that I don't understand some critical issue. Can you please help me understand this part: It seems like people want releases, starting with 10.0, to be named things like 10.0, 10.1, 10.2,..., but for the purposes of communicating with programs like nagios refer to them as 10.0.0, 10.0.1, 10.0.2 Is that right? That's the part that really annoys me, and I keep trying to argue for not doing that, and people keep replying to other parts of my messages rather than replying to the core part of what I am saying. Why would any sensible person want a release to sometimes be called "10.4", but the exact same release sometimes referred to as "10.0.4"? This is just going to confuse average software users, as they would never expect that 10.4 and 10.0.4 are the same thing. Have I misunderstood what is being proposed? The only reason I talk about using the middle number for this other purpose is to forestall people assuming that they can elide the middle number of a three number system, such that it gets elided sometimes but not other times. I was quite clear in my email this morning that I'm not arguing for a three number system. I'm perfectly ok with a two number system. I just don't want a "let's confuse everybody by making each and every release have two different names" system. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 alert > users that you've not just back ported a bug fix, but a feature. Any new > features that are not compatible don't get back ported. So instead of having about 5 branches to maintain, we will end up with 5N branches, because we will still have to support the initial .0 branches of each major, plus .1, .2 ... of each major branch? Granted, we could have major releases not every year but perhaps every 2 or 3 years; non-catversion-bumping patches would still be released quicker than that, in middle-number-increasing releases. But like Robert, I don't think that the number of features we could add this way would be numerous enough to support this idea in the long run. I think this increases the load on committers many times. Count me out. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
> 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 versioning system masquerading as a three > > part versioning system, or vice versa. > > To clarify my concern, I never want to have to write code like this: > > CASE WHEN pg_version eq '11.1' OR pg_version eq '11.0.1' THEN foo() >WHEN pg_version eq '11.2' OR pg_version eq '11.0.2' THEN > bar() > > or > > if (0 == strcmp(pg_version_string, "11.1") || 0 == > strcmp(pg_version_string, "11.0.1")) > foo(); > else if (0 == strcmp(pg_version_string, "11.2") || 0 == > strcmp(pg_version_string, "11.0.2")) > bar(); > > either in sql, perl, c, java, or anywhere else. As soon as you have two > different > formats for the version string, you get into this hell. Yeah, ok, you may > have > a sql level function for this, but I'm thinking about applications somewhat > removed > from a direct connection to the database, where you can't be sure which format > you'll be handed. > > Now you argue for keeping the middle number on pure compatibility grounds... I am not arguing for that. I'm arguing against having two different versions of the same thing. If you go with a two part versioning scheme that is sometimes written as a three part versioning scheme, you make every bit of code that deals with it from now on have to deal with both possible versions in order to be robust. My preference is to have a three part versioning scheme where all three parts have different purposes. But since the community seems to have no interest in that, and have largely (if not universally) rejected that idea, I'm falling back to merely arguing that if we're going to have a two part versioning system, we should do that everywhere, and if we can't do that everywhere, then we should do that nowhere. You appear to be arguing that we should have a versioning scheme that is sometimes two parts, and sometimes three parts, but when three parts, always make the middle number zero. The part of that which bothers me most is not the "always zero" part. It's the "sometimes two parts, sometimes three parts" part. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
> 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 upon our project policy. And any rare exception can >>> justifiably be called a bug fix because, face it, it would only happen if >>> someone reports a bug. >> >> Why are you refusing to acknowledge the difference between features that >> require a pg_upgrade and features that don't? > > The amount of additional committer work that would be created by > making that distinction would be large. Currently, we're on an annual > release cycle. Every commit that's not a bug fix gets committed to > exactly one branch: master. Inevitably, there are multiple changes > per cycle - dozens, probably - that change initial catalog contents > and would therefore require pg_upgrade. > > Suppose we switched to a semi-annual release cycle where every other > release required a pg_upgrade, so once per year same as now, and the > other ones did not. The only way to do that would be to have two > active development branches, one of which accepts only changes that > don't bump catversion or xlog_page_magic and the other of which > accepts changes of all sorts. Every patch that qualifies for the > no-pg-upgrade-required branch would have to be committed twice, > resolving conflicts as necessary. > > Also, over time, the number of supported branches would approximately > double. With a five year support window, it's currently about six. > If you had another set of semi-major releases in between the main set > of releases, you'd end up with 11 or 12 active branches, which would > make back-patching significantly more burdensome than currently. > > 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 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 alert users that you've not just back ported a bug fix, but a feature. Any new features that are not compatible don't get back ported. If you fix a bug on master during development, you can back port that as well. But instead of bumping the middle number, you bump the last number. Somebody running a version that is three major versions back could still get the advantage of new features, so long as those new features are not incompatible. It's frequently not nearly so easy to run pg_upgrade as it is to run rpm -U. You get downtime either way, but the elapsed time of that downtime is orders of magnitude different. Someone else running that same version from three major versions ago can take a more conservative policy, and only upgrade bug fixes, and forego the back ported features. You still have one major version release per year. At that time, you can also release back-port versions of prior major versions. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 >> justifiably be called a bug fix because, face it, it would only happen if >> someone reports a bug. > > Why are you refusing to acknowledge the difference between features that > require a pg_upgrade and features that don't? The amount of additional committer work that would be created by making that distinction would be large. Currently, we're on an annual release cycle. Every commit that's not a bug fix gets committed to exactly one branch: master. Inevitably, there are multiple changes per cycle - dozens, probably - that change initial catalog contents and would therefore require pg_upgrade. Suppose we switched to a semi-annual release cycle where every other release required a pg_upgrade, so once per year same as now, and the other ones did not. The only way to do that would be to have two active development branches, one of which accepts only changes that don't bump catversion or xlog_page_magic and the other of which accepts changes of all sorts. Every patch that qualifies for the no-pg-upgrade-required branch would have to be committed twice, resolving conflicts as necessary. Also, over time, the number of supported branches would approximately double. With a five year support window, it's currently about six. If you had another set of semi-major releases in between the main set of releases, you'd end up with 11 or 12 active branches, which would make back-patching significantly more burdensome than currently. Now maybe you have some other idea in mind, but I don't quite understand what it is. It's not likely to ever happen that we go through a whole 12 month release cycle and then get to the end of it and say "huh, I guess we never bumped catversion or xlog_page_magic". If that ever does happen, it's probably a sign that nobody is doing any meaningful feature development any more. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 system, or vice versa. > > To clarify my concern, I never want to have to write code like this: > > CASE WHEN pg_version eq '11.1' OR pg_version eq '11.0.1' THEN foo() >WHEN pg_version eq '11.2' OR pg_version eq '11.0.2' > THEN bar() > > or > > if (0 == strcmp(pg_version_string, "11.1") || 0 == > strcmp(pg_version_string, "11.0.1")) > foo(); > else if (0 == strcmp(pg_version_string, "11.2") || 0 == > strcmp(pg_version_string, "11.0.2")) > bar(); > > either in sql, perl, c, java, or anywhere else. As soon as you have two > different > formats for the version string, you get into this hell. Yeah, ok, you may > have > a sql level function for this, but I'm thinking about applications > somewhat removed > from a direct connection to the database, where you can't be sure which > format > you'll be handed. > Now you argue for keeping the middle number on pure compatibility grounds... The correct format is: 110001 and 110002 Which pretty much boils down to "we're keeping the middle number but it will always be zero". So, I'll suppose you are giving a +1 to keeping the human-readable display 10.0.x - and will let other's interpret your reasons as they will. David J.
Re: [HACKERS] 10.0
> 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 write code like this: CASE WHEN pg_version eq '11.1' OR pg_version eq '11.0.1' THEN foo() WHEN pg_version eq '11.2' OR pg_version eq '11.0.2' THEN bar() or if (0 == strcmp(pg_version_string, "11.1") || 0 == strcmp(pg_version_string, "11.0.1")) foo(); else if (0 == strcmp(pg_version_string, "11.2") || 0 == strcmp(pg_version_string, "11.0.2")) bar(); either in sql, perl, c, java, or anywhere else. As soon as you have two different formats for the version string, you get into this hell. Yeah, ok, you may have a sql level function for this, but I'm thinking about applications somewhat removed from a direct connection to the database, where you can't be sure which format you'll be handed. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
> > 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 only happen if > someone reports a bug. Why are you refusing to acknowledge the difference between features that require a pg_upgrade and features that don't? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 confusing and weird > >> versioning scheme. > >> > >> It does have the advantage that that compare a two-part major like > >> 090401 vs 090402 won't be confused when they compare 100100 and 100200, > >> since it'll be 11 and 12. So it's more backward-compatible. But > >> ugly. > >> > > > > Realistically, though, we're more likely to end up with 10.0.1 than > > 10.1. I don't think we're anywhere near plumbing the depths of the > > stuff which will break because folks are parsing our version numbers > > with regexes. In more major software, this will break nagios > > check_postgres. > > Having a 3 part versioning scheme where the middle portion is always > zero makes the least sense to me of any of the proposals. If we're going > to have the pain and hurting of moving to a 2 part versioning scheme, > and breaking nagios and what not, then lets just get on with it. If we're > going to keep all three parts, can we please use my proposal earlier in > this thread where A.B.C are allocated for: > > C++: bug fixes only > B++: new features added, but still backward compatible with prior version > A++: new features added, not backward compatible, pg_upgrade required > > If every new feature release ends up requiring pg_upgrade, then B will > always be zero, which is no worse than your proposal. But at least users > can > refer to part B to learn something useful, namely whether they will need to > run pg_upgrade as part of upgrading their existing cluster. > > This has the advantage that new minor features, like adding a new guc, can > be released sooner than the next major release, but does not have to be > released in disguise as if it were a bug fix. > > 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. > > 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 only happen if someone reports a bug. If we keep the middle digit it will be for compatibility reasons. Let's not cause people to infer something that isn't true by saying it could change. David J.
Re: [HACKERS] 10.0
> 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 advantage that that compare a two-part major like >> 090401 vs 090402 won't be confused when they compare 100100 and 100200, >> since it'll be 11 and 12. So it's more backward-compatible. But >> ugly. >> > > Realistically, though, we're more likely to end up with 10.0.1 than > 10.1. I don't think we're anywhere near plumbing the depths of the > stuff which will break because folks are parsing our version numbers > with regexes. In more major software, this will break nagios > check_postgres. Having a 3 part versioning scheme where the middle portion is always zero makes the least sense to me of any of the proposals. If we're going to have the pain and hurting of moving to a 2 part versioning scheme, and breaking nagios and what not, then lets just get on with it. If we're going to keep all three parts, can we please use my proposal earlier in this thread where A.B.C are allocated for: C++: bug fixes only B++: new features added, but still backward compatible with prior version A++: new features added, not backward compatible, pg_upgrade required If every new feature release ends up requiring pg_upgrade, then B will always be zero, which is no worse than your proposal. But at least users can refer to part B to learn something useful, namely whether they will need to run pg_upgrade as part of upgrading their existing cluster. This has the advantage that new minor features, like adding a new guc, can be released sooner than the next major release, but does not have to be released in disguise as if it were a bug fix. 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. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 does have the advantage that that compare a two-part major like > > 090401 vs 090402 won't be confused when they compare 100100 and 100200, > > since it'll be 11 and 12. So it's more backward-compatible. But > > ugly. > > Realistically, though, we're more likely to end up with 10.0.1 than > 10.1. I don't think we're anywhere near plumbing the depths of the > stuff which will break because folks are parsing our version numbers > with regexes. In more major software, this will break nagios > check_postgres. > > I'm not happy with it, but I believe that's where we'll end up. Pulling back a bit from this a bit, I am pretty sure that the fix for the new announced version numbers, so long as our new policy is clear and won't be changed again for the foreseeable future has the following characteristics: - Not a show-stopper, i.e. people will not drop support in their products for PostgreSQL over this. - A Matter of Programming that really is small. The difference between the old three-part/six-digit version encoding and the new two-part/four-digit version encoding is stark and simple, as is the code to handle it, even if it's regex. By the time we get to PostgreSQL 100.0, the first starship will already be back, and the 9.x PostgreSQLs will be in older to people using them then that the Zuse Z1 https://en.wikipedia.org/wiki/Konrad_Zuse is to us now. Just my $.02. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 090402 won't be confused when they compare 100100 and 100200, > since it'll be 11 and 12. So it's more backward-compatible. But > ugly. > Realistically, though, we're more likely to end up with 10.0.1 than 10.1. I don't think we're anywhere near plumbing the depths of the stuff which will break because folks are parsing our version numbers with regexes. In more major software, this will break nagios check_postgres. I'm not happy with it, but I believe that's where we'll end up. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.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 name instead of > renaming back to Postgres. I'm not a fan of it. > Well ... no. We kept the PostgreSQL name for three reasons. Back in 2005, which was the last time we could have reasonably changed it, nobody had the time/energy to do all of the search-and-replace-and-contact-every-packager required. The folks who were most enthusiastic about the change wanted someone else to do the work. Plus, our Japanese community, which was like 40% of our worldwide community at the time, was opposed to the change. The third reason is that we have a registered trademark on "PostgreSQL", but "postgres" is public domain. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 PostgreSQL name instead of > renaming back to Postgres. I'm not a fan of it. I, on the other hand, am a big fan of backward-compatibility. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 it. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 updates >> that offer the same stability guarantees. Users would be less likely to be >> intimidated by 10.0.1 than they would be 10.1. And it gives users a >> consistent story they can apply to any version whether 9.x or 10.0+ > > > And matches semver. > >> >> 2) If we ever do release incompatible feature releases on older branches >> -- or more likely some fork does -- it gives them a natural way to number >> their release. > > Seems unlikely, though. > > 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 > 090402 won't be confused when they compare 100100 and 100200, since it'll be > 11 and 12. So it's more backward-compatible. But ugly. Ugliness is a highly subjective qualifier. OTOH, Backwards compatibility, at least when the checks are properly written :-), is a very objective benefit. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 updates >> that offer the same stability guarantees. Users would be less likely to be >> intimidated by 10.0.1 than they would be 10.1. And it gives users a >> consistent story they can apply to any version whether 9.x or 10.0+ >> > > And matches semver. > If we were or ever expected to have some kind of semver policy then a numbering scheme matching semver would make sense. We don't and so having one just allows people to make invalid assumptions. This possibility was known when the discussion at pgCon happened and, IIUC, the decision to use 10.0 was made. And this thread went on for quite a while prior to that. Lets let this die, please. Or at worse wait until we open HEAD up for 10.0 and someone commits the fully fleshed out versioning changes to the docs. David J.
Re: [HACKERS] 10.0
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 less likely to be > intimidated by 10.0.1 than they would be 10.1. And it gives users a > consistent story they can apply to any version whether 9.x or 10.0+ > And matches semver. > 2) If we ever do release incompatible feature releases on older branches > -- or more likely some fork does -- it gives them a natural way to number > their release. > Seems unlikely, though. 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 090402 won't be confused when they compare 100100 and 100200, since it'll be 11 and 12. So it's more backward-compatible. But ugly. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: [HACKERS] 10.0
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_setting('server_version_num'); > > Or get server_version from the GUC_REPORT params sent at connect-time, avoiding a round-trip. That's how drivers do it. Client application should just ask their driver, they shouldn't need to be poking around to get the version directly. It'd be better if server_version_num was also GUC_REPORT, but it isn't. I still think it should be. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: [HACKERS] 10.0
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 been keeping up with hackers, sorry if this has been suggested already but... Why don't we just *actually* keep the middle digit and *actually* have it always be zero? 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 less likely to be intimidated by 10.0.1 than they would be 10.1. And it gives users a consistent story they can apply to any version whether 9.x or 10.0+ 2) If we ever do release incompatible feature releases on older branches -- or more likely some fork does -- it gives them a natural way to number their release.
Re: [HACKERS] 10.0
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 need to know what version you're handling in a Makefile, and today that's pretty ugly (especially when something is stamped as beta, since it breaks assumptions about numeric). -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 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 database >> >> won't >> >> be >> >> able to use it. The one thing that absolutely has to be >> >> cross-version >> >> is the method of determining which version you're running against. >> >> >> >> >> >> >> >> >>> We're talking about a function that doesn't currently exist anyway. >> >> >> >> >> >> >> >> >> Huh? We're talking about PQserverVersion(), comparisons to >> >> >> PG_VERSION_NUM, >> >> >> and related APIs. Those most certainly exist now, and trying to >> >> >> supplant >> >> >> them seems like a giant waste of time. >> >> >> >> >> >> On the other hand, parsing fields out of version() mechanically has >> >> >> been >> >> >> deprecated for as long as those other APIs have existed (which is >> >> >> since >> >> >> 8.0 or so). version() is only meant for human consumption, so I see >> >> >> no >> >> >> reason it shouldn't just start returning "10.0", "10.1", etc. If >> >> >> that >> >> >> breaks anyone's code, well, they should have switched to one of the >> >> >> easier methods years ago. >> >> > >> >> > >> >> > The original post was: >> >> > >> >> >> IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= >> >> >> 9.3 >> >> > >> >> > and \df *version* on my HEAD doesn't show any other options. >> >> >> >> Right. It's the only way to handle things on the SQL level well, >> >> that, and pg_settings approaches. In other words, there is no easier >> >> way. I think it's pretty reasonable to assume there's a lot more code >> >> interfacing with the database from SQL than from C. >> > >> > >> > We could stand to be more explicit here. The docs for version() >> > indicated >> > the server_version_num should be used for "machine processing". >> >> whoop! I didn't know about that setting. I guess it dismantles a lot >> of the case for more aggressive action. That said, maybe it's a good >> idea to construct the versioning change so that 10.x releases have a >> server_version_num > 9.x releases and leave the other functions alone >> (assuming that wasn't already the plan). >> >> > Option E: Give the DBA control. If they know they have one or more >> > mis-behaving applications but it is out their control to patch the code >> > to >> > work properly they can change this supposedly human-readable output to >> > conform the historical x.y.z format. This would disabled by default. >> > Humans can easily interpret both versions so please save the comment >> > about >> > not having GUCs that influence user-visible behavior. If your argument >> > for >> > changing the format outright is "its for human consumption only" then >> > apparently this output should not be considered important enough to >> > adhere >> > to that rule. Non-humans depending on its format are subject to our, or >> > the >> > DBA's, whims. >> >> Nah -- my argument could be restated as "I wasn't aware of the machine >> variant of the version #". Do you think it's a good idea to have the >> machine version number be 10 for version 10.0? What would 10.1 >> be? 100100 or 11? > > > Sleeping on it I too came to the conclusion that the GUC was largely an > undesirable option. > > 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. > > Tom's comment back on May 14th (different thread) was that we'd basically > redefine the minor portion to be 4-digits instead of 2. That makes sense -- I'm good then. Thanks for engaging merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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: > >> >> > >> >> 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 determining which version you're running against. > >> >> > >> >> > >> >>> We're talking about a function that doesn't currently exist anyway. > >> >> > >> >> > >> >> Huh? We're talking about PQserverVersion(), comparisons to > >> >> PG_VERSION_NUM, > >> >> and related APIs. Those most certainly exist now, and trying to > >> >> supplant > >> >> them seems like a giant waste of time. > >> >> > >> >> On the other hand, parsing fields out of version() mechanically has > >> >> been > >> >> deprecated for as long as those other APIs have existed (which is > since > >> >> 8.0 or so). version() is only meant for human consumption, so I see > no > >> >> reason it shouldn't just start returning "10.0", "10.1", etc. If > that > >> >> breaks anyone's code, well, they should have switched to one of the > >> >> easier methods years ago. > >> > > >> > > >> > The original post was: > >> > > >> >> IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3 > >> > > >> > and \df *version* on my HEAD doesn't show any other options. > >> > >> Right. It's the only way to handle things on the SQL level well, > >> that, and pg_settings approaches. In other words, there is no easier > >> way. I think it's pretty reasonable to assume there's a lot more code > >> interfacing with the database from SQL than from C. > > > > > > We could stand to be more explicit here. The docs for version() > indicated > > the server_version_num should be used for "machine processing". > > whoop! I didn't know about that setting. I guess it dismantles a lot > of the case for more aggressive action. That said, maybe it's a good > idea to construct the versioning change so that 10.x releases have a > server_version_num > 9.x releases and leave the other functions alone > (assuming that wasn't already the plan). > > > Option E: Give the DBA control. If they know they have one or more > > mis-behaving applications but it is out their control to patch the code > to > > work properly they can change this supposedly human-readable output to > > conform the historical x.y.z format. This would disabled by default. > > Humans can easily interpret both versions so please save the comment > about > > not having GUCs that influence user-visible behavior. If your argument > for > > changing the format outright is "its for human consumption only" then > > apparently this output should not be considered important enough to > adhere > > to that rule. Non-humans depending on its format are subject to our, or > the > > DBA's, whims. > > Nah -- my argument could be restated as "I wasn't aware of the machine > variant of the version #". Do you think it's a good idea to have the > machine version number be 10 for version 10.0? What would 10.1 > be? 100100 or 11? Sleeping on it I too came to the conclusion that the GUC was largely an undesirable option. 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. Tom's comment back on May 14th (different thread) was that we'd basically redefine the minor portion to be 4-digits instead of 2. David J.
Re: [HACKERS] 10.0
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 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 determining which version you're running against. >> >> >> >> >> >>> We're talking about a function that doesn't currently exist anyway. >> >> >> >> >> >> Huh? We're talking about PQserverVersion(), comparisons to >> >> PG_VERSION_NUM, >> >> and related APIs. Those most certainly exist now, and trying to >> >> supplant >> >> them seems like a giant waste of time. >> >> >> >> On the other hand, parsing fields out of version() mechanically has >> >> been >> >> deprecated for as long as those other APIs have existed (which is since >> >> 8.0 or so). version() is only meant for human consumption, so I see no >> >> reason it shouldn't just start returning "10.0", "10.1", etc. If that >> >> breaks anyone's code, well, they should have switched to one of the >> >> easier methods years ago. >> > >> > >> > The original post was: >> > >> >> IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3 >> > >> > and \df *version* on my HEAD doesn't show any other options. >> >> Right. It's the only way to handle things on the SQL level well, >> that, and pg_settings approaches. In other words, there is no easier >> way. I think it's pretty reasonable to assume there's a lot more code >> interfacing with the database from SQL than from C. > > > We could stand to be more explicit here. The docs for version() indicated > the server_version_num should be used for "machine processing". whoop! I didn't know about that setting. I guess it dismantles a lot of the case for more aggressive action. That said, maybe it's a good idea to construct the versioning change so that 10.x releases have a server_version_num > 9.x releases and leave the other functions alone (assuming that wasn't already the plan). > Option E: Give the DBA control. If they know they have one or more > mis-behaving applications but it is out their control to patch the code to > work properly they can change this supposedly human-readable output to > conform the historical x.y.z format. This would disabled by default. > Humans can easily interpret both versions so please save the comment about > not having GUCs that influence user-visible behavior. If your argument for > changing the format outright is "its for human consumption only" then > apparently this output should not be considered important enough to adhere > to that rule. Non-humans depending on its format are subject to our, or the > DBA's, whims. Nah -- my argument could be restated as "I wasn't aware of the machine variant of the version #". Do you think it's a good idea to have the machine version number be 10 for version 10.0? What would 10.1 be? 100100 or 11? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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) If we're looking at forward only changes, is it possible to introduce a JSONB output to it. Then people can rip out whichever component they want at will. For example: { "full": 10.0, "major": 10, "patchlevel": 0 } and whatever else may be pertinent. I used numeric types above but they can be strings if that works better. We have the capability to provide (semi-)structured data. Might be an idea to make greater use of it. -- "A search of his car uncovered pornography, a homemade sex aid, women's stockings and a Jack Russell terrier." - http://www.dailytelegraph.com.au/news/wacky/indeed/story-e6frev20-118083480 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 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 determining which version you're running against. > >> > >> > >>> We're talking about a function that doesn't currently exist anyway. > >> > >> > >> Huh? We're talking about PQserverVersion(), comparisons to > >> PG_VERSION_NUM, > >> and related APIs. Those most certainly exist now, and trying to > supplant > >> them seems like a giant waste of time. > >> > >> On the other hand, parsing fields out of version() mechanically has been > >> deprecated for as long as those other APIs have existed (which is since > >> 8.0 or so). version() is only meant for human consumption, so I see no > >> reason it shouldn't just start returning "10.0", "10.1", etc. If that > >> breaks anyone's code, well, they should have switched to one of the > >> easier methods years ago. > > > > > > The original post was: > > > >> IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3 > > > > and \df *version* on my HEAD doesn't show any other options. > > Right. It's the only way to handle things on the SQL level well, > that, and pg_settings approaches. In other words, there is no easier > way. I think it's pretty reasonable to assume there's a lot more code > interfacing with the database from SQL than from C. > 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_setting('server_version_num'); I'd say we should at least provide the above as an example; the reader can find their way to Chapter 18.1 if they are curious about alternatives. On the topic of option "D" I'd be fine with fine with functions: and ; but that is independent of this discussion. Option E: Give the DBA control. If they know they have one or more mis-behaving applications but it is out their control to patch the code to work properly they can change this supposedly human-readable output to conform the historical x.y.z format. This would disabled by default. Humans can easily interpret both versions so please save the comment about not having GUCs that influence user-visible behavior. If your argument for changing the format outright is "its for human consumption only" then apparently this output should not be considered important enough to adhere to that rule. Non-humans depending on its format are subject to our, or the DBA's, whims. David J.
Re: [HACKERS] 10.0
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 database won't be able to use it. The one thing that absolutely has to be cross-version is the method of determining which version you're running against. >> >> >>> We're talking about a function that doesn't currently exist anyway. >> >> >> Huh? We're talking about PQserverVersion(), comparisons to >> PG_VERSION_NUM, >> and related APIs. Those most certainly exist now, and trying to supplant >> them seems like a giant waste of time. >> >> On the other hand, parsing fields out of version() mechanically has been >> deprecated for as long as those other APIs have existed (which is since >> 8.0 or so). version() is only meant for human consumption, so I see no >> reason it shouldn't just start returning "10.0", "10.1", etc. If that >> breaks anyone's code, well, they should have switched to one of the >> easier methods years ago. > > > The original post was: > >> IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3 > > and \df *version* on my HEAD doesn't show any other options. Right. It's the only way to handle things on the SQL level well, that, and pg_settings approaches. In other words, there is no easier way. I think it's pretty reasonable to assume there's a lot more code interfacing with the database from SQL than from C. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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-version is the method of determining which version you're running against. We're talking about a function that doesn't currently exist anyway. Huh? We're talking about PQserverVersion(), comparisons to PG_VERSION_NUM, and related APIs. Those most certainly exist now, and trying to supplant them seems like a giant waste of time. On the other hand, parsing fields out of version() mechanically has been deprecated for as long as those other APIs have existed (which is since 8.0 or so). version() is only meant for human consumption, so I see no reason it shouldn't just start returning "10.0", "10.1", etc. If that breaks anyone's code, well, they should have switched to one of the easier methods years ago. The original post was: IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3 and \df *version* on my HEAD doesn't show any other options. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 much sense as a different function name, since the output is fundamentally different than version(). -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 determining which version you're running against. > We're talking about a function that doesn't currently exist anyway. Huh? We're talking about PQserverVersion(), comparisons to PG_VERSION_NUM, and related APIs. Those most certainly exist now, and trying to supplant them seems like a giant waste of time. On the other hand, parsing fields out of version() mechanically has been deprecated for as long as those other APIs have existed (which is since 8.0 or so). version() is only meant for human consumption, so I see no reason it shouldn't just start returning "10.0", "10.1", etc. If that breaks anyone's code, well, they should have switched to one of the easier methods years ago. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 with the parsing wart this long, so lets > just add an explicit output version to 10.0. > > 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. 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 determining which version you're running against. We're talking about a function that doesn't currently exist anyway. So no matter what, you won't be able to use it if you're interested in <10.0 (or <9.6 if we went with one of the other proposals). Unless folks were thinking this is something that would be backpatched? -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 function and >> other places suggesting to use that instead for 9.6. >> >> B) Preserve x.y.z as returned by version() and show server_version for >> those usages only, with 'y' being always 0 for 10.0 and beyond. For >> all other purposes (marketing/documentation/etc) that structure would >> *not* be preserved, and we would put notes in the documentation >> describing why the extra digit is there. >> >> C) Do neither A or B, and let our users discover such issues on their own. > > > 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 with the parsing wart this long, so lets > just add an explicit output version to 10.0. > > 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. 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 determining which version you're running against. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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.6. B) Preserve x.y.z as returned by version() and show server_version for those usages only, with 'y' being always 0 for 10.0 and beyond. For all other purposes (marketing/documentation/etc) that structure would *not* be preserved, and we would put notes in the documentation describing why the extra digit is there. C) Do neither A or B, and let our users discover such issues on their own. 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 with the parsing wart this long, so lets just add an explicit output version to 10.0. 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. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 minor updates 10.1, >> 10.2, etc. >> >> * The year after, 11.0. Etc cetera. >> > > Yes. Please! > > I get tired of explaining to people that PostgreSQL "9.x" isn't a thing, > that yes, 9.3 and 9.4 really _do_ have incompatible data directories and > replication protocols, and that when the docs say "major version" they don't > mean "major version as you might actually expect" but "first two version > number parts". > > Lets get rid of this user-baffling wart. Agreed. What's been nagging me is what the impacts to users could be. I just stumbled across some code that *could* have been broken, but by sheer luck it's safe: /* only postgres 9.3+ supports row count from 'COPY' */ IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3 THEN GET DIAGNOSTICS _RowCount = ROW_COUNT; ELSE _RowCount := (LineCount(_ScratchFileName, (SELECT WorkFolder FROM CDSControl)))::BIGINT - 1; END IF; LineCount() is a pl/sh wrapper to 'wc -l' that supports this wrapper to COPY so that it always gives a count of rows loaded. I guess this is a pretty hacky way of doing version checks inside of SQL but I suppose changing the structure of the version number might break similar approaches to parsing the string. This regex would in fact continue to work properly, but it did raise some alarm bells. Looking ahad, IMO we could: 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.6. B) Preserve x.y.z as returned by version() and show server_version for those usages only, with 'y' being always 0 for 10.0 and beyond. For all other purposes (marketing/documentation/etc) that structure would *not* be preserved, and we would put notes in the documentation describing why the extra digit is there. C) Do neither A or B, and let our users discover such issues on their own. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 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. Etc cetera. >>> Yes. Please! >> >> Hear, hear! >> >> Sadly, we're too late for 9.6, but we can start with 10.0 and finish >> this silliness once and for good. > > +1! > +1 -- Jaime Casanova www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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. >>> >>> * Next year's major release will be 10.0, with minor updates 10.1, >>> 10.2, etc. >>> >>> * The year after, 11.0. Etc cetera. >>> >>> >> Yes. Please! > > Hear, hear! > > Sadly, we're too late for 9.6, but we can start with 10.0 and finish > this silliness once and for good. +1! -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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, with minor updates 10.1, > > 10.2, etc. > > > > * The year after, 11.0. Etc cetera. > > > > > Yes. Please! > > I get tired of explaining to people that PostgreSQL "9.x" isn't a thing, > that yes, 9.3 and 9.4 really _do_ have incompatible data directories and > replication protocols, and that when the docs say "major version" they > don't mean "major version as you might actually expect" but "first two > version number parts". > > Lets get rid of this user-baffling wart. Hear, hear! Sadly, we're too late for 9.6, but we can start with 10.0 and finish this silliness once and for good. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 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. Etc cetera. > > Yes. Please! I get tired of explaining to people that PostgreSQL "9.x" isn't a thing, that yes, 9.3 and 9.4 really _do_ have incompatible data directories and replication protocols, and that when the docs say "major version" they don't mean "major version as you might actually expect" but "first two version number parts". Lets get rid of this user-baffling wart. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: [HACKERS] 10.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, testing, packaging) to do it, with an increase in the >> middle number. Maybe we will never find the resources to do that, but >> why should that assumption get baked into the numbering scheme? > > If we were to do that today, it'd just be an increase in the minor number. > I don't see why we'd need to change that approach. We've rejected back-patching such improvements in the past on the grounds that it was at least theoretically possible that it would negatively affect someone, even if it were a win overall for most people, and users shouldn't be forced to adopt that risk in order to get security or corruption bug fixes that go into the minor number increments. > The real blocking > factors there are about manpower and stability of the resulting code, not > about whether you need some special version numbering to describe it. If we did overcome the man-power and stability problems, we would certain run into the version numbering one pretty quickly, under both the existing versioning system and the two-part system. And I don't think that using something at least vaguely like SemVer is really "special", if anything it is less special than either the existing or the dominant proposal. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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. Then the idea was that PostgreSQL 6.0 was the sixth >> major release counting those as the first five releases. > The last release out of Berkeley was 4.2. Correct --- I have a copy of that tarball. > Then Postgres95 was "5", and then PostgreSQL started at 6. I wasn't actually around at the time, but our commit history starts with this: Author: Marc G. Fournier Branch: master Release: REL6_1 [d31084e9d] 1996-07-09 06:22:35 + Postgres95 1.01 Distribution - Virgin Sources The first mention of 6.anything is here: Author: Bruce Momjian Branch: master Release: REL6_1 [a2b7f6297] 1996-12-28 02:01:58 + Updated changes for 6.0. I see no references in the commit history to 5.anything, but there are some references like this: Author: Marc G. Fournier Branch: master Release: REL6_1 [491b9b89c] 1996-08-26 20:38:52 + The patch that is applied at the end of the email makes sure that these conditions are always met. The patch can be applied to any version of Postgres95 from 1.02 to 1.05. After applying the patch, queries using indices on bpchar and varchar fields should (hopefully ;-) ) always return the same tuple set regardless to the fact whether indices are used or not. Submitted by: Gerhard Reithofer So I think that the Postgres95 releases were retrospectively redefined as being the "5.x" series, but no release was ever made with such a number. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 there was ever a 5.x release). 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. Then the idea was that PostgreSQL 6.0 was the sixth major release counting those as the first five releases. The last release out of Berkeley was 4.2. Then Postgres95 was "5", and then PostgreSQL started at 6. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 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. Then the idea was that PostgreSQL 6.0 was the sixth major release counting those as the first five releases. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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". But it's likely premature to get into those sorts of details, since it's not clear to me that we have a consensus to change at all. It would be interesting to actually release snapshots after commit fests, ie: 10.dev.0, 10.dev.1, etc. And +1 for ditching major.major.minor in favor of major.minor.0. It's high time we stop this silliness. IMHO the beginning of parallelism that we have now is more than enough to justify 10.0, but that consideration pales compared to fixing the version numbering system itself. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 discussions and remove the confusion the current versioning scheme has (I too heard way to many times about people using postgres8 or postgres9). Even worse: I've been told that a company was using "PostgreSQL 8.5" ^_^ That's not necessarily the version numbers fault. That's them using an alpha version.. (Yes, I've run into a customer just a couple of years ago that were still on 8.5 alpha) It was their fault, obviously. There were not using the alpha version, they were using 8.3 but they thought it was 8.5 (and yes, that's terrible that they provide information without checking it). Anyway, and not being version number's fault, having one less number may have helped here and probably in other cases too. Álvaro -- Álvaro Hernández Tortosa --- 8Kdata
Re: [HACKERS] 10.0
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 heard way to many times about people >> using postgres8 or postgres9). >> > > Even worse: I've been told that a company was using "PostgreSQL 8.5" > ^_^ That's not necessarily the version numbers fault. That's them using an alpha version.. (Yes, I've run into a customer just a couple of years ago that were still on 8.5 alpha) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Re: [HACKERS] 10.0
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 worse: I've been told that a company was using "PostgreSQL 8.5" ^_^ Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 it as being major plus four-digit minor, really. > Under the current maintenance scheme we never get anywhere near minor > release 99 before a branch dies ... but having some more breathing room > there would not be a bad thing. Perhaps that would be a good topic for the developer meeting in Ottawa? That's just in two days, so it looks like a good timing. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 > middle number. Maybe we will never find the resources to do that, but > why should that assumption get baked into the numbering scheme? If we were to do that today, it'd just be an increase in the minor number. I don't see why we'd need to change that approach. The real blocking factors there are about manpower and stability of the resulting code, not about whether you need some special version numbering to describe it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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...@biglumber.com > > I proposed in that thread that we always increment the first number, > never increment the second number, and increment the third exactly as we do > now for bugfix releases. I like this idea, roughly in line with SemVer. 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 middle number. Maybe we will never find the resources to do that, but why should that assumption get baked into the numbering scheme? Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
"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 current maintenance scheme we never get anywhere near minor release 99 before a branch dies ... but having some more breathing room there would not be a bad thing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
-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 number, never increment the second number, and increment the third exactly as we do now for bugfix releases. I think moving to a two-number format is a mistake: what exactly will PQserverVersion() return in that case? But I understand people have a hard time swallowing the "never change the middle number" portion of this idea. Thus, here's a slight variation on that theme: what if we simply reversed the expectations of bumping the first number, and put the onus on people to change the *middle* number? Thus, the next release by default will be 10.0.0, the one after that will be by default 11.0.0, and so on. We can reserve the middle number for "lesser" releases - which may never happen - but at least we will have a mechanism to provide for them. So rather than the current spate of messages like this: "This should be called 12.0 because of cool feature X and reason Y" we would get the rare message like this: "We don't really have much for this release, maybe it should just be 11.1?" - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201605142247 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAlc34/UACgkQvJuQZxSWSsgQLgCeJS9v69R5C3BJxNy2ih1P2Tk8 xngAn0UQoSn6y3iOwMr5aHSKzuBh+3Xn =wzw4 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 broken. The major number is the normal > place to do that. The problem with that idea is that *minor* backwards compatibility breakage is much more likely in each-and-every version than major breakage is at any time in the foreseeable future. The last major breakage we really had was version 8.3, which if we'd been going by compatibility should have been 9.0 (also for other reasons). And if we adopt the "backwards compatibility" approach, then we'll just be switching from the argument we're having now to the argument of "is this enough breakage to rate a .0? Yes/No?". Which argument will be just as long as this one. So, my vote is now +1 to go to the 2-part numbering scheme. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 not very practical for PostgreSQL because the major versions are not that different from each other and all are treated the same development-wise. So it would be a huge drain on the project to discuss which major version should be a .0 unless planning towards them steps up significantly. So I think the (slight) consensus is more that all major versions are mostly equal and hence only one version number is needed. Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 be nice to encode, but how is .0 different from .1 then? You make sound like .0 would be similar to Ubuntu's LTS which is not the case, unless you want to propose that only .0 releases get 5 years and not the in-betweens? That'd be a shame. Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
+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 the problem, we are project with long history, which releases major version every year, I don't see why version number shouldn't reflect that. About changing first digit only when we break compatibility with applications for example by removing money type. We do have app breaking incompatibilities in almost every major version so in effect we'd have to bump the first digit every time anyway if we went with that schema (I still remember working on db that was kept on 8.3 till EOL just because we changes hashtext implementation, or db which was kept back because of removal plgpsql rename clause where nobody wanted to rewrite couple thousand function which used it and there are many examples like that). -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 changes we put >> in. >> > > Well, if we adopt 2-part version numbers, it will be. Maybe that's the > easiest thing? Then we never have to have this discussion again, which > certainly appeals to me ... Wasn't there some controversy about switching to major.minor versioning this in -advocacy? http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5...@biglumber.com IMO, this versioning is pretty good and people understand it well, with the other will be using postgres 13 by 2020, which isn't far away. ;) -- Martín Marquéshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 opinion on it being too late after beta1 has been released. -- Martín Marquéshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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'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 number and those where we choose to bump the second. It's all about marketing. So to me, merging those numbers would be an anti-marketing move. I think it's a good move: it would be more honest and transparent about what the numbers mean, not less so. "Marketing" and "honesty" are not antonyms, and thinking that marketing is unimportant for the success of the project is not correct. +1 JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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've shipped a beta, rebranding is way too confusing. So, not that it makes any difference at this point, but this seems to fly in the face of what you said before. http://www.postgresql.org/message-id/24567.1456864...@sss.pgh.pa.us Unless you thought that beta wasn't going to be out until the fall. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 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 number and those where we choose to bump the > second. It's all about marketing. So to me, merging those numbers would > be an anti-marketing move. I think it's a good move: it would be more > honest and transparent about what the numbers mean, not less so. "Marketing" and "honesty" are not antonyms, and thinking that marketing is unimportant for the success of the project is not correct. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 > major-major upgrade, specially if people support this idea in forums like > saying: "10.0 will come with amazing features, because version is bumped > from 9.6". > > So +1 to call 10.0 the next version and 11.0 the one after that. +1. Another data point: Debian did exactly this x.y.z -> x.y switch (with exactly the same major/minor version number semantics re major/minor upgrades) a few years ago [*], and it was a real relief. "Debian 9" just sounds so much better than "Debian 9.6". IMHO getting rid of the problem that people are always saying "I'm using Postgres 9" when asked about the major version should be enough reason to change to a x.y scheme. Christoph [*] There was a period of two releases where we bumped the x and y was kept 0, before the y was ultimately dropped. (3.0 - 3.1 - 4.0 - 5.0 - 6.0 - 7 - 8) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 number and those where we choose to bump the second. It's all about marketing. So to me, merging those numbers would be an anti-marketing move. I think it's a good move: it would be more honest and transparent about what the numbers mean, not less so. If having two "major" numbers is a marketing game, and if it works in such a way, I'd immediately say let's keep it. Decisions like the one debated here should be driven more from what is going to help user adoption rather than -hackers personal taste. BTW, none of these approaches seem dishonest to me. 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 major-major upgrade, specially if people support this idea in forums like saying: "10.0 will come with amazing features, because version is bumped from 9.6". So +1 to call 10.0 the next version and 11.0 the one after that. Álvaro -- Álvaro Hernández Tortosa --- 8Kdata -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
> 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 understand correctly..." > > I'm not sure that you do... > > Our scheme is, in your terms, basically: > > .micro > > where is a decimal. > > You cannot reason about the whole and fraction portions of the decimal > independently. There is no point in having them as separate parts of the version number unless you can do precisely that. If the only difference between choosing 9.7.0 vs. 10.0.0 is that you consulted a numerologist who moonlights as an astrologer, then, yes, you can't tell anything from the first number independent from the second. I was simply arguing against the numerology/astrology approach to version numbering. The only other way out of the numerology/astrology approach is the one Tom Lane suggested, and that you seem to support. This whole conversation makes me think the community has done a poor job of communicating the nature of the (major,minor) portion of the (major,minor,micro) numbering scheme. I always assumed it was more respectable that it now appears to have been. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 your terms, basically: .micro where is a decimal. You cannot reason about the whole and fraction portions of the decimal independently. When changes backward compatibility can be broken - with respect to both API and implementation. It therefore makes sense to > reserve room in the numbering scheme to be clear and honest about when > backwards compatibility has been broken. The major number is the normal > place to do that. I'm not convinced there is enough risk here to compromise the present in order to accommodate some unknown scenario that may never even come to pass. David J.
Re: [HACKERS] 10.0
> 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 will go down from now on." > > Tom brought up my own thoughts on the rest - but, really, this is a cynical > way of looking at things. Every company I have worked for that has been taken over by pointy haired bosses has almost immediately begun playing games with the version numbers, product names, etc, and dropped the focus on quality, performance, bug fixes, etc. I don't expect that from the postgresql community, but I find discussion on the mailing lists about using a "wow, 10.x.x release! how amazing" marketing line rather crass. I doubt many people in the tech industry generally feel all that differently about it. I've never worked with a programmer or DBA who was impressed with these kinds of version number bumps. I fully agree mine is a cynical point of view. 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 broken. The major number is the normal place to do that. Just my .2 cents. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 the rest - but, really, this is a cynical way of looking at things. At least insofar as whether marketing has say over what exact version number is assigned to a release should, and here likely does, have almost zero influence on the quality of the code that went into said release. This entire discussion and timeline is proof of exactly that. We have the option to market version 10.0.0 if we so choose but during the entire past year -core hasn't cared whether the release they are working toward is eventually numbered 9.6.0 or 10.0.0 - and I posit that nothing would have changed had it been decided a year ago that we were going to release 10.0.0. I'll accept that addressing the broader community's confusion regarding our version numbering scheme is a problem worth addressing. Therefore I support moving to a simple "version.patch" system for next year's release. Having accepted the importance of accepting the broader community's opinions changing to 10 now after we've released beta1 would be counter-productive. Personally, having come in around the 8.2 release I didn't, and quite honestly still don't, care why the decision was made to release 9.0 instead of 8.5. Mainly because the feature oriented decisions to increment seems to be largely focused on the DBA - which is it not my primary concern. For me, the inclusion of window functions would have been enough to warrant a major version bump - and CTEs as well. Both of those went into 8.4. So not only is it getting harder to gain critical mass in a single release (which is good - it means we are not settling for the easy stuff and are properly breaking down harder features into small releaseables) but the stuff we are keying on are likely of secondary importance to a large number of users. David J.
Re: [HACKERS] 10.0
> 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 will go down from now on." 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 number and those where we choose to bump the second. It's all about marketing. So to me, merging those numbers would be an anti-marketing move. I think it's a good move: it would be more honest and transparent about what the numbers mean, not less so. >> I find your argument persuasive if there is no possibility of ever needing >> a major number to bump. But if anything like what I described above could >> someday happen, it seems the major.minor.micro format would come in >> handy. Perhaps the problem (from my perspective) is that the major number >> has been used for purely marketing purposes in the past, and I've tried to >> avert my eyes to that. But going forward, my vote (worth less than half a >> cent I'm sure) is to stop using it for marketing reasons. > > Per a long discussion on -advocacy, nobody has any specific plans to do > substantial breakage of backwards compatibility. Theoretically we might > someday want to change the on-disk format, but nobody has plans to do so > in the immediate future. How long should we hold out for that? Until 9.27? > > And I don't find dropping the "money" type to be substantial breakage. If minor number bumps mean, "dump and restore is necessary, but client programs are guaranteed to still work", then dropping the "money" type is a different kind of action. Maybe you don't think it matters much, but for somebody who is using it in a client application, that matters. Likewise, somebody who has a struct in a client program that expects Oid to fit into 32 bits *needs* to go through their client programs if Oid ever gets changed to 64 bit. (Pigs will probably fly first, but just for instance.) I'm not advocating any of these changes today. I just think they are different kinds of changes from adding new functions while leaving all old functions in tact. As cool as parallel query is (and I'd happily buy Robert or Amit a beer) it doesn't break any functionality in client applications that ignore it, so far as I can see. Using parallel query as a motivation for increasing the major number stems from a marketing instinct, not from sound engineering practices. Now that I've said that, I'll sit back and wait for the REL10_0_DEVEL branch to appear in the repo. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 discontinue the previous .0 > > Well maybe the 5 year support cycle would be nice to encode, but how is > .0 different from .1 then? You make sound like .0 would be similar to > Ubuntu's LTS which is not the case, unless you want to propose that only > .0 releases get 5 years and not the in-betweens? That'd be a shame. > The opinion seems to be that major.0 is some kind of magic incantation in the broader world of users...so its basically "since the last time we incremented major this is what we've done - 80% of which is new to you only if you've lived under a rock for the past four years". David J.
Re: [HACKERS] 10.0
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 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 number and those where we choose to bump the >> > second. It's all about marketing. So to me, merging those numbers would >> > be an anti-marketing move. I think it's a good move: it would be more >> > honest and transparent about what the numbers mean, not less so. > I find your argument persuasive if there is no possibility of ever needing > a major number to bump. But if anything like what I described above could > someday happen, it seems the major.minor.micro format would come in > handy. Perhaps the problem (from my perspective) is that the major number > has been used for purely marketing purposes in the past, and I've tried to > avert my eyes to that. But going forward, my vote (worth less than half a > cent I'm sure) is to stop using it for marketing reasons. Per a long discussion on -advocacy, nobody has any specific plans to do substantial breakage of backwards compatibility. Theoretically we might someday want to change the on-disk format, but nobody has plans to do so in the immediate future. How long should we hold out for that? Until 9.27? And I don't find dropping the "money" type to be substantial breakage. -- -- Josh Berkus Red Hat OSAS (any opinions are my own) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
> 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 protocols, etc. > > 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 can't imagine that we'd ever intentionally break > dump/restore compatibility. While we have changed the network protocol, > and likely will again, we kept on supporting the old protocol alongside, > and almost certainly would do so again. There are too many compatibility > constraints that we have to meet in order to be a usable database at all, > so we're never going to just blow it up and start over. Well, those are just examples. Other candidate examples would be dropping datatypes such as 'money' that were maybe not a good idea to begin with, or somehow ditching the 'timestamp' vs. 'timestamptz' distinction, or changing to 64-bit Oids, such that software that interacts with postgresql has to change accordingly. Another such idea would be supporting 64-bit varlena lengths and dropping large object support. Another would be dropping support for older communication protocols whose presence in the server out of the box makes the server a security vulnerability. (I am not asserting the presence of such vulnerabilities, but just speculating on the possibility that such vulnerabilities might be discovered in the future that make it useful to ditch older, insecure protocols.) I suspect other folks could add lots of other stuff to this list. >> 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 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 number and those where we choose to bump the > second. It's all about marketing. So to me, merging those numbers would > be an anti-marketing move. I think it's a good move: it would be more > honest and transparent about what the numbers mean, not less so. I find your argument persuasive if there is no possibility of ever needing a major number to bump. But if anything like what I described above could someday happen, it seems the major.minor.micro format would come in handy. Perhaps the problem (from my perspective) is that the major number has been used for purely marketing purposes in the past, and I've tried to avert my eyes to that. But going forward, my vote (worth less than half a cent I'm sure) is to stop using it for marketing reasons. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
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 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 can't imagine that we'd ever intentionally break dump/restore compatibility. While we have changed the network protocol, and likely will again, we kept on supporting the old protocol alongside, and almost certainly would do so again. There are too many compatibility constraints that we have to meet in order to be a usable database at all, so we're never going to just blow it up and start over. > 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 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 number and those where we choose to bump the second. It's all about marketing. So to me, merging those numbers would be an anti-marketing move. I think it's a good move: it would be more honest and transparent about what the numbers mean, not less so. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers