10 ms·

The point about renaming major versions is baffling. First of all, if your suggestion is that you use Rails 4 vs. Rails 5, that's a version number, one that may

The point about renaming major versions is baffling. First of all, if your suggestion is that you use Rails 4 vs. Rails 5, that's a version number, one that may be handled a little differently by your package manager (or it may not, if you already pin to major versions). But the premise that a major version conveys no more information than a full rename is simply wrong. Is libfoo n + 1 more similar to libfoo n, or libbaz m? In extremely rare cases, it will be more similar to libbaz m than libfoo n, but in 99% of cases, that's not true. Even if that is not perfectly reliable, that probability conveys information. P.S. I'm not commenting on the other ideas raised by the article.

jacobush 9y ago
The whole thing made me think of "A plan for the improvement of spelling in the English language" http://www.plainlanguage.gov/examples/humor/marktwain.cfm http://www.plainlanguage.gov/examples/humor/marktwain.cfm
- hyperpape 9y ago
  To the best of my knowledge, that's not a joke, even though I assumed it was the first time I read it. Mark Twain believed in spelling reform (https://en.wikipedia.org/wiki/English-language_spelling_reform https://en.wikipedia.org/wiki/English-language_spelling_refo...). But I find claims that he didn't write it: http://grammar.ccc.commnet.edu/grammar/twain.htm http://grammar.ccc.commnet.edu/grammar/twain.htm
- Avshalom 9y ago
  Though of course 'th' should be replace by 'y' not 'x', which has historic precedent.
  - abritinthebay 9y ago
    Not actually true. It’s a common misconception that gave us fake pseudoarchaic old English like “ye olde whatever”. That comes due to the confusion of the old thorn character Þ or þ which got all mangled and misread.
    - Avshalom 9y ago
      pronouncing it as a vowel when it was supposed to be a 'th' is psuedoarchiac, spelling/typesetting 'th' as 'y' is a kludge with precedent though.
      - abritinthebay 9y ago
        In the sense that early printing presses didn’t have a thorn character, yes. But it was an incorrect substitution then, and still would be now.
        groovy2shoes 9y ago
        I've been studying paleography for about a year now, and I really don't find this to be true. This seems to be a common story, one that I've heard before and one which makes plenty of sense, but also one which seems to be false. Certainly, the use of <y> in place of <þ> for certain common abbreviations would've become most common in the early days of the printing press—not because presses couldn't have a thorn character, but because it didn't make sense to spend resources making one if it wasn't necessary. However, the substitution of <y> for <þ> in scribal abbreviations started happening in English manuscripts even before the introduction of the printing press in England. In the most common scripts at the time (cursiva anglicana and later bastarda anglicana), <y> and <þ> were already very similar (the only difference being which of the two strokes had the descender—both letters have a closed bowl in these scripts), so similar that it was common in bookhands to write a small dot above <y> to aid the reader even when <þ> was still visually distinct. You can see this clearly in [1], written c. 1399. Use of either character to represent <th> was already becoming quite rare in the late Middle English period, and remained in use almost exclusively as a scribal shorthand; it's not uncommon to encounter manuscripts in which <þ> and <th> are mixed freely. I can't say for certain why it is that <y> started to be substituted for <þ> in manuscripts. Obviously in the common hands of the time they're visually very similar, yet I'd imagine anyone who'd been educated as a scribe would be able to spot and write the difference. Perhaps it was a stylistic choice. But it did happen: you can see an example at [2]. This document was written c. 1445. Gutenberg's printing press is thought to have been invented at this time, but it wouldn't arrive in England until Caxton set one up c. 1476. It seems very unlikely to me that the printing press had anything to do with the initial substitution, though I'd imagine that the press was a major nail in thorn's coffin. [1]: https://en.wikipedia.org/wiki/Confessio_Amantis#/media/File:Palaeography_(Quaritch)_plate15.jpg https://en.wikipedia.org/wiki/Confessio_Amantis#/media/File:... [2]: http://medievalwriting.50megs.com/scripts/examples/chancery6.htm http://medievalwriting.50megs.com/scripts/examples/chancery6... (both of these documents are written in a bastarda anglicana)
mjw1007 9y ago
Right, he isn't really talking about changing the way we assign version numbers to software projects. Rather he's talking (in a rather confusing way) about changing the way we convert names-and-version-numbers into identifiers used in package management systems. The convention he suggests is basically what Debian has always done for C libraries (putting the soname in the package name), so it's certainly a plausible way to manage things.
- marcosdumay 9y ago
  If I stop using Debian some day, it will probably be because of that habit of pushing version information into part of a package's name. It completely breaks upgrades. Newer versions aren't compatible with older versions, yet there's nothing telling apt that it should upgrade other stuff depending on the older version first. Also, who is to say wether foo5.3 is newer or older than foo5, and since foo5 depends on bar3.2, while foo5.3 depends on bar3.2a, what package do you have to upgrade first?
  - snuxoll 9y ago
    libbar3 still has a package version of 3.2.1, libfoo5 still has a package version of 5.3.0. Debian putting soname’s into package names is actually quite handy as it allows side-by-side installation of multiple versions of a library with ease.
    - sjellis 9y ago
      It's very useful for applications that don't guarantee API or data format compatibility between major versions. If you were running PostgreSQL 8, then under no circumstances would you want a silent upgrade to PostgreSQL 9, because 9 would refuse to read the data storage files from 8 and not start up: PostgreSQL required the administrator to handle migration between storage versions.
grzm 9y ago
> a major version conveys no more information I understand where you're coming from: a complete project name change is something very different. I also think this is something that's commonly misunderstood. From the article: > conveys no more actionable information The key here is actionable. What will change in what you as someone who consumes this third-party code will have to do if you adopt a major version bump versus a new library? Unless the new version is API compatible with the old one, you're likely going to have to do some major work in incorporating the new version; if the API is backwards compatible, it's not really a major version bump. The further a different library is from the one you're currently using is of course going to require a different level of rework, but that's part of what a major version bump signifies. I see what you're getting at with respect to some arbitrary new library, but if the new major version (with a new name) is from the same maintainer, Rails2 vs Rails v2 isn't so different from what you're going to need to do in your code. As for which name you change, I think that's where the rubber meets the road. What's the name the code is referred to in your application? That's the one that really matters, and where a name change is warranted. If the language affords module namespacing, the new library is just a new require/import. Major versions aren't drop-in replacements. If the libraries are namespaced, you can conceivably use them side-by-side in the same codebase as you migrate. This is potentially very powerful. As a practical example, in one Java library I've been working on that has a long history, it's able to use various versions of JUnit in the same testing suite exactly because the different versions are namespaced. Another example at a different level is being able to install more than one version of, say, python or sqlite, on the same system. Some packages name the binaries with a suffix, e.g., python27 or python3, so you can include and have both of them on your path without conflict. When you install current versions of sqlite, the binary is explicitly sqlite3 so as to not be confused with older, incompatible versions.
- mrighele 9y ago
  > Unless the new version is API compatible with the old one, you're likely going to have to do some major work in incorporating the new version. A new major revision of a library means that there are some non-backward compatible changes, and in many cases this means a limited number of fixes have to be done. Also in general it is expected that one will want to upgrade, so probably those changes are documented. Also hopefully the two libraries will share the same main concepts so using the new version will not be terribly different from the old. Of course it is not always the case, see Angular, were two unrelated frameworks share the same name (I really think they should have changed the name).
kabdib 9y ago
Yeah, the old name + a new version number does indeed convey information; there's going to be some common ancestry, anyway. It also means that the users of the library aren't forced to deal with a sea of cutesy names, we've already got too many of those. "Well, we need to upgrade the Epic Flatuence server to Smelly Gangrene in order to stay compatible with whatever they're calling the next version of Wild Dingo --" "Screaming Fist." "The Russian version?" "No, by a guy out of Vancouver." "Right. Next, let's talk about Your Mother ..."
derefr 9y ago
There's basically another part of the version-tuple that we compress into the same position as the "major" version: the number of complete codebase rewrites that the code has experienced. Often V1 and V2 of an application, especially, will have effectively nothing in common. Often they'll be developed by separate people who happened to inherit the name of the original, or "take up the reins" after the original became abandonware—but, either way, decided to just write a new one themselves rather than continuing on with the old. At that point, there is really no difference between calling it "libfoo (n + 1).0" and calling it "libbaz 1.0". If you want to convey ancestry, you could add another preceding number, and that's often what people do—in the package name. For example, sqlite3 vs. sqlite4. If you wanted to make this "part of" the version tuple, you could: just have a super-major number before the major number.
SolarNet 9y ago
I disagree. A great recent example is that DirectX 12 is more similar to Vulkan, than it is DirectX 11 or OpenGL 4. I would actually say it's quite common. I've seen numerous times where a new version of a project is more similar to other projects than it's previous iteration. The reason is simple: the field has progressed. Now certainly there are new "major" releases that are simply breaking changes with no fundamental changes, but I think it depends on your field: native libraries rarely change because it's well worn, the web changes every few days it seems like. But my point is that if we should distinguish between: conceptual changes, breaking changes and the iteration number (e.g. non-breaking changes and patches), and we want to simplify it, then we should merge breaking changes and conceptual changes, as described by the article.

jacobush 9y ago

The whole thing made me think of "A plan for the improvement of spelling in the English language" http://www.plainlanguage.gov/examples/humor/marktwain.cfm http://www.plainlanguage.gov/examples/humor/marktwain.cfm

hyperpape 9y ago
To the best of my knowledge, that's not a joke, even though I assumed it was the first time I read it. Mark Twain believed in spelling reform (https://en.wikipedia.org/wiki/English-language_spelling_reform https://en.wikipedia.org/wiki/English-language_spelling_refo...). But I find claims that he didn't write it: http://grammar.ccc.commnet.edu/grammar/twain.htm http://grammar.ccc.commnet.edu/grammar/twain.htm
Avshalom 9y ago
Though of course 'th' should be replace by 'y' not 'x', which has historic precedent.
- abritinthebay 9y ago
  Not actually true. It’s a common misconception that gave us fake pseudoarchaic old English like “ye olde whatever”. That comes due to the confusion of the old thorn character Þ or þ which got all mangled and misread.
  - Avshalom 9y ago
    pronouncing it as a vowel when it was supposed to be a 'th' is psuedoarchiac, spelling/typesetting 'th' as 'y' is a kludge with precedent though.
    - abritinthebay 9y ago
      In the sense that early printing presses didn’t have a thorn character, yes. But it was an incorrect substitution then, and still would be now.
      - groovy2shoes 9y ago
        I've been studying paleography for about a year now, and I really don't find this to be true. This seems to be a common story, one that I've heard before and one which makes plenty of sense, but also one which seems to be false. Certainly, the use of <y> in place of <þ> for certain common abbreviations would've become most common in the early days of the printing press—not because presses couldn't have a thorn character, but because it didn't make sense to spend resources making one if it wasn't necessary. However, the substitution of <y> for <þ> in scribal abbreviations started happening in English manuscripts even before the introduction of the printing press in England. In the most common scripts at the time (cursiva anglicana and later bastarda anglicana), <y> and <þ> were already very similar (the only difference being which of the two strokes had the descender—both letters have a closed bowl in these scripts), so similar that it was common in bookhands to write a small dot above <y> to aid the reader even when <þ> was still visually distinct. You can see this clearly in [1], written c. 1399. Use of either character to represent <th> was already becoming quite rare in the late Middle English period, and remained in use almost exclusively as a scribal shorthand; it's not uncommon to encounter manuscripts in which <þ> and <th> are mixed freely. I can't say for certain why it is that <y> started to be substituted for <þ> in manuscripts. Obviously in the common hands of the time they're visually very similar, yet I'd imagine anyone who'd been educated as a scribe would be able to spot and write the difference. Perhaps it was a stylistic choice. But it did happen: you can see an example at [2]. This document was written c. 1445. Gutenberg's printing press is thought to have been invented at this time, but it wouldn't arrive in England until Caxton set one up c. 1476. It seems very unlikely to me that the printing press had anything to do with the initial substitution, though I'd imagine that the press was a major nail in thorn's coffin. [1]: https://en.wikipedia.org/wiki/Confessio_Amantis#/media/File:Palaeography_(Quaritch)_plate15.jpg https://en.wikipedia.org/wiki/Confessio_Amantis#/media/File:... [2]: http://medievalwriting.50megs.com/scripts/examples/chancery6.htm http://medievalwriting.50megs.com/scripts/examples/chancery6... (both of these documents are written in a bastarda anglicana)

mjw1007 9y ago

Right, he isn't really talking about changing the way we assign version numbers to software projects. Rather he's talking (in a rather confusing way) about changing the way we convert names-and-version-numbers into identifiers used in package management systems. The convention he suggests is basically what Debian has always done for C libraries (putting the soname in the package name), so it's certainly a plausible way to manage things.

marcosdumay 9y ago
If I stop using Debian some day, it will probably be because of that habit of pushing version information into part of a package's name. It completely breaks upgrades. Newer versions aren't compatible with older versions, yet there's nothing telling apt that it should upgrade other stuff depending on the older version first. Also, who is to say wether foo5.3 is newer or older than foo5, and since foo5 depends on bar3.2, while foo5.3 depends on bar3.2a, what package do you have to upgrade first?
- snuxoll 9y ago
  libbar3 still has a package version of 3.2.1, libfoo5 still has a package version of 5.3.0. Debian putting soname’s into package names is actually quite handy as it allows side-by-side installation of multiple versions of a library with ease.
  - sjellis 9y ago
    It's very useful for applications that don't guarantee API or data format compatibility between major versions. If you were running PostgreSQL 8, then under no circumstances would you want a silent upgrade to PostgreSQL 9, because 9 would refuse to read the data storage files from 8 and not start up: PostgreSQL required the administrator to handle migration between storage versions.

grzm 9y ago

> a major version conveys no more information I understand where you're coming from: a complete project name change is something very different. I also think this is something that's commonly misunderstood. From the article: > conveys no more actionable information The key here is actionable. What will change in what you as someone who consumes this third-party code will have to do if you adopt a major version bump versus a new library? Unless the new version is API compatible with the old one, you're likely going to have to do some major work in incorporating the new version; if the API is backwards compatible, it's not really a major version bump. The further a different library is from the one you're currently using is of course going to require a different level of rework, but that's part of what a major version bump signifies. I see what you're getting at with respect to some arbitrary new library, but if the new major version (with a new name) is from the same maintainer, Rails2 vs Rails v2 isn't so different from what you're going to need to do in your code. As for which name you change, I think that's where the rubber meets the road. What's the name the code is referred to in your application? That's the one that really matters, and where a name change is warranted. If the language affords module namespacing, the new library is just a new require/import. Major versions aren't drop-in replacements. If the libraries are namespaced, you can conceivably use them side-by-side in the same codebase as you migrate. This is potentially very powerful. As a practical example, in one Java library I've been working on that has a long history, it's able to use various versions of JUnit in the same testing suite exactly because the different versions are namespaced. Another example at a different level is being able to install more than one version of, say, python or sqlite, on the same system. Some packages name the binaries with a suffix, e.g., python27 or python3, so you can include and have both of them on your path without conflict. When you install current versions of sqlite, the binary is explicitly sqlite3 so as to not be confused with older, incompatible versions.

mrighele 9y ago
> Unless the new version is API compatible with the old one, you're likely going to have to do some major work in incorporating the new version. A new major revision of a library means that there are some non-backward compatible changes, and in many cases this means a limited number of fixes have to be done. Also in general it is expected that one will want to upgrade, so probably those changes are documented. Also hopefully the two libraries will share the same main concepts so using the new version will not be terribly different from the old. Of course it is not always the case, see Angular, were two unrelated frameworks share the same name (I really think they should have changed the name).

kabdib 9y ago

Yeah, the old name + a new version number does indeed convey information; there's going to be some common ancestry, anyway. It also means that the users of the library aren't forced to deal with a sea of cutesy names, we've already got too many of those. "Well, we need to upgrade the Epic Flatuence server to Smelly Gangrene in order to stay compatible with whatever they're calling the next version of Wild Dingo --" "Screaming Fist." "The Russian version?" "No, by a guy out of Vancouver." "Right. Next, let's talk about Your Mother ..."

derefr 9y ago

There's basically another part of the version-tuple that we compress into the same position as the "major" version: the number of complete codebase rewrites that the code has experienced. Often V1 and V2 of an application, especially, will have effectively nothing in common. Often they'll be developed by separate people who happened to inherit the name of the original, or "take up the reins" after the original became abandonware—but, either way, decided to just write a new one themselves rather than continuing on with the old. At that point, there is really no difference between calling it "libfoo (n + 1).0" and calling it "libbaz 1.0". If you want to convey ancestry, you could add another preceding number, and that's often what people do—in the package name. For example, sqlite3 vs. sqlite4. If you wanted to make this "part of" the version tuple, you could: just have a super-major number before the major number.

SolarNet 9y ago

I disagree. A great recent example is that DirectX 12 is more similar to Vulkan, than it is DirectX 11 or OpenGL 4. I would actually say it's quite common. I've seen numerous times where a new version of a project is more similar to other projects than it's previous iteration. The reason is simple: the field has progressed. Now certainly there are new "major" releases that are simply breaking changes with no fundamental changes, but I think it depends on your field: native libraries rarely change because it's well worn, the web changes every few days it seems like. But my point is that if we should distinguish between: conceptual changes, breaking changes and the iteration number (e.g. non-breaking changes and patches), and we want to simplify it, then we should merge breaking changes and conceptual changes, as described by the article.