10 ms·

Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not wheth

• pawelmurias 5y ago
  > Can upgrade without having to deal with breaking changes This is actually very important. If something is a major change or not is pretty subjective.
  • eru 5y ago
    It is pretty subjective, but not entirely so, and I would guess there's a pretty clear consensus around whether this is a big deal or not in the community?
• lanstin 5y ago
  Not really from my perspective. I want know if there is any reason to not upgrade due to my existing code base breaking. Extra new features I could use are not such a reason. New reserved words are such a reason. If someone is using a new feature, I can just say "make sure you have the newest version, also here's my reason for keeping close to the edge of current versions, so that you amortize the labor of keeping up to date rather than pinning and then having some big migration project in 5 years."
• robto 5y ago
  In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.11, respectively[0]. In Clojure land they just say 1.x, even when large new features are added. I like this because it emphasizes the community's commitment backwards compatibility, which I greatly value. I've spent a good deal of time writing Javascript, where library developers seem to have very little respect for their users and constantly break backwards compatibility. In ecosystems like that, upgrading fills me with dread. When I see a library on version 4, I have learned to keep looking - if they weren't thoughtful enough about their API design for the first 3 major releases, I shouldn't expect it to be much better going forwards. For an application, I'm pretty open to version numbers signifying big features - Firefox and Chrome do this, and it's helpful with marketing. But for a programming language? A programming language is a tool, and when upgrading you need to carefully read the changelog anyways. A programming language is no different from a library (in Clojure it literally is a library), and backwards compatibility is /literally/ the main thing I care about. Is my tool going to intrude on /my/ schedule, and force me to make changes /it/ wants instead of being able to spend my time making changes /I/ care about? I want to know that. [0]This is apparently an awful example as I've just learned that Java is actually doing the major version only thing. It still sort of works because the only reason they can do that is because they Will Not Break Compatiblity.
  • linkdd 5y ago
    > In Java people regularly refer to a particular JDK version as a Java 17 or Java 11, even though they actually refer to versions 1.17 and 1.8, respectively. 17 -> 1.17, 11 -> 1.8, this is bothering me way to much for no good reason.
    • danudey 5y ago
      Clarification: * Java 8 is Java 1.8.0 * Java 11 is Java 11.0.11 (at the moment) * Java 17 is Java 17.0.1 (at the moment) SunOS/Solaris is what I use when I want to get nerd-rage mad about minutae: https://en.wikipedia.org/wiki/Oracle_Solaris#Version_history https://en.wikipedia.org/wiki/Oracle_Solaris#Version_history
    • 5y ago
• WastingMyTime89 5y ago
  > The major version should represent major language changes, not whether its a breaking change or not Why? Old code still work and unless you are purposefully maintaining an old system you are expected to use the last version anyway. What does it actually change that generics were introduced in version 1.18 rather than 2.0? From now on, Go has generics. As there is no breaking change, it’s not like you had to keep using the previous version to opt out.
  • eru 5y ago
    To play devil's advocate: many people are forced by circumstances beyond their control to use various old versions, or provide libraries and want to support people who are forced to use various old versions.
• cortesoft 5y ago
  Wait, why wouldn’t it matter for a language? I want to know if I can compile my existing project with the new version… isn’t that an important thing to know?
  • MereInterest 5y ago
    Because in most languages, maintaining backwards compatibility is absolutely sacrosanct. It's not that you check the version number to know if your code will still compile. You check the name of the language to know if your code will still compile. (Yes, there are exceptions to this, but those tend to be cautionary tales. Python 3 is a better language than Python 2, but took a decade to gain adoption because it broke backwards compatibility.) Since backwards compatibility is already a given for languages, you can then have the major version number indicate feature additions, rather than always being a constant value as semantic versioning would require.
    • cortesoft 5y ago
      I dont know if backwards compatibility is absolutely sacrosanct in most languages... for C/C++, sure... but I know Rust has broken backwards compatibility before, as has Python as you mention, and Ruby, too. I don't think it is as sacrosanct as you think it is, especially for relatively new languages under heavy development.
• 13415 5y ago
  It makes no sense to replace a meaningful and helpful criterion - whether it breaks code or not - by some purely subjective assessment of what's a "major change." That just leads to usual version creep, from "Go 2.2" to "Go 3.0", to "Go 4.0", to (inevitable) "Go 10", "Go 11", "Go 11 Pro", "Go 11 Ultimate Edition",...
  • Groxx 5y ago
    It could be worse, they could start naming these "Go WXGA+", "Go i99900kf", and "Go for Women".
    • maximus-decimus 5y ago
      Diet Go
      • chihuahua 5y ago
        New Goke
    • SAI_Peregrinus 5y ago
      Go 3.2 Gen 2x2!
    • eru 5y ago
      You joke, but using marketing version names _in addition_ to semantic versions might actually make sense.
• mpalmer 5y ago
  Sounds like you think this is some kind of "Web 2.0" situation, but that was just a marketing term. Languages are software; they are dependencies of other software (the only unavoidable dependency!) and as such should absolutely be versioned. Versioning isn't for marketing or providing easy ways for users to remember when features were released. It's a tool for change management. Exciting features often come with breaking changes, but not vice versa.
  • wyattpeak 5y ago
    versioning != semantic versioning Semantic versioning is an approach to versioning. It's an approach which, as GP stated, was designed specifically to help with dependency updating. GP isn't proposing that languages shouldn't be versioned, they're saying that semantic versioning is the wrong approach to versioning for a language.
    • mpalmer 5y ago
      Well I did inadvertently leave out the word semantic but it's certainly what I was describing.
• cpuguy83 5y ago
  There are already effectively 2 ways to deal with language changes: 1. Min version in go.mod 2. Add a build tag for what to do for new/old version of go (These tags are automatic, you just need to set them in the files)
• tptacek 5y ago
  They're not using 2.0 because 2.0 might have breaking changes, and they don't want to burn the version number for something that doesn't break the Go 1.0 compatibility promise. Makes sense.
• maximus-decimus 5y ago
  That's just like, your opinion, man.
  • jayniz 5y ago
    Mark it zero!
• geofft 5y ago
  Semantic versioning solves one specific problem that's worth solving - whether you can (expect to) automatically upgrade. That is a problem people have with languages just as much as libraries, and it is a problem that affects both big changes and small just as much as it affects libraries. It is not the only way to solve this problem, but that problem very much needs to be addressed. When a language adds any features, if your dependencies (whether real library dependencies or just things you're copying from Stack Overflow) start using the new features, you must upgrade to the new language version. That is an inherent usability constraint, and every time a language designer chooses to add a feature, they're making a tradeoff. But if upgrading to the new language version is trivial, then it's generally a worthwhile tradeoff. For instance, suppose I find some code that uses Python's removeprefix() method on strings. I need to use Python 3.9 or newer to use that code. It doesn't matter that this is a very small feature. However, I can generally expect to upgrade my Python 3.8 code to Python 3.9 without trouble. It's different from, say, code that uses Unicode strings. For that code, I need to upgrade from Python 2 to Python 3, which I can expect to cause me trouble. The version numbers communicate that. It's true that Python 3 was a "big" change - but "big" isn't really the point. The point is that I can't use Python 2 code directly with Python 3 code, but I can use Python 3.8 code directly with Python 3.9 code. There are plenty of "big" changes happening within the Python 3 series, such as async support, that were made available in a backwards-compatible manner. As it happens, Python does not use semantic versioning. But they have a deprecation policy which requires issuing warnings for two minor releases: https://www.python.org/dev/peps/pep-0387/ https://www.python.org/dev/peps/pep-0387/ It's technically possible, I think, that a change like Unicode strings could happen within the Python 3.x series, but that's okay, provided they follow the documented versioning policy. This policy addresses the same question that semantic versioning does, but it provides a different answer: you can always upgrade to one or two minor versions newer, but at that point you must stop and address deprecation warnings before upgrading further. You are, of course, free to also have a marketing version of your project to communicate how big and exciting the changes are. Windows is a great example here: Windows 95 was 4.0 (communicating both backwards incompatibility with 3.1 and major changes) and Windows 7 was 6.1 (communicating backwards compatibility with Vista but still major changes).
  • wheybags 5y ago
• socialdemocrat 5y ago
  Get your point, but I kind of like it. It tells some really important info, and they are hardly alone. Python 3.x was breaking change. Until they they stayed in 2.x versioning a long time. And we will never see a Python 4.x
  • cozzyd 5y ago
    But many languages try really hard not to make breaking changes. With good reason...
  • throwaway19937 5y ago
    Python also makes breaking changes in minor releases; 3.5 introduced async/await and 3.7 made them reserved keywords.
  • eru 5y ago
    > And we will never see a Python 4.x Why?
• dragonwriter 5y ago
  > Sure, but semantic versioning really is the wrong kind of versioning to use for a language. A language or API (things you program against) are pretty much the things for which SemVer makes sense. > The major version should represent major language changes, not whether its a breaking change or not I don’t care if changes are “major”, I care if the code I wrote for version X is expected to need modification to work correctly in version Y. SemVer gives me that, Subjective Importance Versioning does not.
  • chenzhekl 5y ago
    Can't agree more. One important information that the version number gives me is that if upgrading to newer versions will break my code. SemVer gives me that.
  • garmaine 5y ago
    Arguably a language should NEVER have breaking changes large enough to warrant a SemVer major version update. Rename or fork the language if you want to do that. Such major language overhauls in the past have been a huge waste of developer time as they go back to rewrite affected code.
    • notfed 5y ago
      Java 10 introduced "var", which broke code with variables named "var". I'm glad they did not introduce a new language JavaWithVar.
      • garmaine 5y ago
        That wouldn't be large enough a change to warrant a new major SemVer. I'm talking about things like python2 -> python3.
        • loo 5y ago
          python2 -> python3 was just a handful of things like that.
        • 5y ago
• SurgeArrest 5y ago
  I thank Go team, that the major version was not increased. You can't imagine how much wider adoption of generics will be as compared if Go went to version 2.0 There are thousands of under-educated and overly-cautious software development managers who would prevent their teams from upgrading to a major version of Go until it is "proven". When it comes to developers there are two types who read changelogs and would know their tool well and take advantage of every small change in each minor version and then there are those who are there for the money, they will find out about a new feature only if manager instructs them to use it.
  • eru 5y ago
    > There are thousands of under-educated and overly-cautious software development managers who would prevent their teams from upgrading to a major version of Go until it is "proven". If semantic versioning is used correctly, like here, that's actually a reasonable-ish attitude.
• p1necone 5y ago
  I would definitely consider a language to be an API. Using semantic versioning makes perfect sense; because it communicates to consumers of the language which versions will require them to change their source code and which will not.
• nirvdrum 5y ago
  I agree. It's a bit odd that I just learned generics were added. I expect minor bumps in language versions to be uneventful. Additionally, I expect a language to essentially never introduce breaking changes, so semantic versioning isn't really telling me anything.
  • eru 5y ago
    > Additionally, I expect a language to essentially never introduce breaking changes, so semantic versioning isn't really telling me anything. I'm afraid that expectation isn't entirely warranted. Especially around standard library issues.
• kelnos 5y ago
  > Sure, but semantic versioning really is the wrong kind of versioning to use for a language. I don't agree. I usually don't care so much when a particular feature was introduced into a language (and if I do, it's usually a Wikipedia search away). I mostly care whether or not code written assuming version X can be compiled with version Y of the compiler. Semantic versioning can tell me the latter. Making versioning arbitrarily depend on what someone considers a "big" feature doesn't help me.
  • eru 5y ago
    You could separate the semantic version from the PR version. The PR version doesn't even have to be numeric. You can give them proper names.
    • swagonomixxx 5y ago
      Disagree with this. Most middle managers wouldn't understand the difference. One canonical version is enough, any more and there's just confusion, not enlightenment.
      • eru 5y ago
        Ubuntu does pretty well with their funny animal names. Nobody confuses those with the numbers.
    • mook 5y ago
      Didn't Java try that? I believe it was Java 1.5 that was originally marketed as Java 5. It was confusing.
  • MereInterest 5y ago
    > I don't agree. I usually don't care so much when a particular feature was introduced into a language I care very much when a feature was introduced into a language, because maintaining compatibility with earlier versions of the language determines what features may be used. If I'm working on a library that needs to be compatible with C++03, then that means avoiding smart pointers and rvalues. If I'm working on a library that needs to be compatible with C++11, then I need to write my own make_unique(). If I'm working on a library that needs to be compatible with C++14, then I need to avoid using structured bindings. If a project allows breaking backwards compatibility, then SemVer is a great way to put that information front and center. If a project considers backwards compatibility to be a given, then there's no point in having a constant value hanging out in front of the version number. > I mostly care whether or not code written assuming version X can be compiled with version Y of the compiler. Semantic versioning can only tell that for the case where X < Y (old code on new compiler). In order to determine it for X > Y (new code on old compiler), you need to know when features were introduced.
• DarylZero 5y ago
  I agree. Also they may have sneaked it in because they're implicitly acknowledging fault in their previous design decision to exclude it.
• naikrovek 5y ago
  define a "major" language change, then. after that, get everyone to agree on that definition. that's why semver works; the definition of major change is defined, and that's when you update the major version number.
  • eru 5y ago
    I have sympathy for your sentiment, but you don't have to come up with a proper definition nor get everyone to agree on that definition. The Go people can just make up reasonable version numbers without having an all encompassing theory with definitions, and they only have to convince themselves, not everyone on earth.
    • naikrovek 5y ago
      > The Go people can just make up reasonable version numbers without having an all encompassing theory with definitions but "breaking change" IS the criteria for reasonable version numbers that they have chosen. "breaking change" is easily tested and well defined. "big change" is as far from well defined as you can get, because "big" is unquantifiable and subject to judgement and interpretation; i.e. a poor candidate for drawing boundaries.
      • eru 5y ago
        The Go people did something reasonable. Yes, agreed. I'm just saying that they could have done something different, if they had wanted to, without working out a complete theory for that different thing.
• eyelidlessness 5y ago
  In my opinion, significant additive changes are addressed more poorly than any other aspect of semver, regardless of the project scope. Additive changes can be breaking changes quite easily, as those additions are adopted within a minor version range, as automated tooling needs to distinguish their presence, as documentation fragments. My next biggest gripe with semver—that 0.y.z has entirely different semantics from any other major version—may actually be semantically better if adopted wholesale. If your interface changes, major version bump. Else you’re fixing bugs or otherwise striving to meet extant expectations.
• asimpletune 5y ago
  Yeah, I think you’re talking about the “vanity bit”
• coldtea 5y ago
  >It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with breaking changes. For a language? Silliness. A language update comes with the most fundamental set of libraries and APIs: the standard library (doubly so in Golang, which has a lot of batteries included). It also potentially affects the behavior (if there are breaking changes) of all other third party libs. The "silliness" part is a non sequitur from what proceeded it (and the following arguments don't justify it either). >Your version is not really telling you the main things you care about. The main thing (nay, only thing) I care about (for my existing code) from a language update is whether there were breaking changes. I could not care less to have reflected in the version number whether a big non-breaking feature was introduced. I can read about it and adopt it (or not) whether there's a accompanying big version number change or not. >It's much much more useful to the users to say, 2.0 introduced generics, it's distinct. That's quite irrelevant, isn't it? It's not useful to users that follow the language (page, forums, blogs, etc.) and would already know which release introduced generics. And it's also not useful to new users that get started with generics from day one of their Go use either. So who would it be useful to? Such a use would make the version number the equivalent of a "we got big new feature for you" blog post.
• giancarlostoro 5y ago
  > Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not Major language changes almost implies breaking changes, like Python 2 to 3 was major changes that break things everything from how modules were changed, where they were, and some syntactic and fundamental changes as well.
• werdnapk 5y ago
  Ruby introduces new language features all the time in minor versions while maintaining backward compatibility. I can pretty much upgrade a minor Ruby version to get access to new language features without worrying about breaking anything.
• titzer 5y ago
  I think we should go back to years (for most software, in fact, not just languages). Languages change slowly enough (or should) that, e.g. "Ada 2021" should be unambiguous enough. For language implementation versions, then we can add semantic numbers afterwards.