Re: 10.0
| От | David G. Johnston |
|---|---|
| Тема | Re: 10.0 |
| Дата | |
| Msg-id | CAKFQuwZNap8OSqLYx0JVZnjioxD=bhbJAmp9yFR_KEqt49DC7g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: 10.0 (Mark Dilger <hornschnorter@gmail.com>) |
| Ответы |
Re: 10.0
(Mark Dilger <hornschnorter@gmail.com>)
Re: 10.0 (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
I don't have a problem with it if humans always use a two part number. I don't read
> 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...).
the number 100004 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 "100001 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 tw
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 not
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 100000. 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 breakage.
David J.
В списке pgsql-hackers по дате отправления: