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 <hornschnor...@gmail.com> > wrote: > >> >> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake <j...@commandprompt.com> >> 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 100004 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. > >