6 ms·

I think i officially hate semver. I seems a good idea at first. But updating the major version of Angular every 6 months, will not help us. Or, semver should s

I think i officially hate semver. I seems a good idea at first. But updating the major version of Angular every 6 months, will not help us. Or, semver should start to update its major version every 4 months, perhaps Angular devs will understand what the term JavaScript fatigue means.

pfooti 10y ago
I dunno. I use hapijs at my day job (and am .. happy .. with it). They're on like version 16.0 so far, but I tend to only actually bump my own installed version every now and again. We basically update if there's a bug we need addressing or whenever it's time to update all our dependencies. Sometimes there's a breaking change we need to work through (often in the plugin ecosystem with stuff like bell for oauth integration), but usually the major changes aren't too painful to transition through. It's still nice to use semver and know what to expect. You just have to get acclimatized to having very large major version numbers. I mean, Chrome is up to version what, 55?
- uncle_joe 10y ago
  Here is an except of the FAQ of semver ''' If even the tiniest backwards incompatible changes to the public API require a major version bump, won’t I end up at version 42.0.0 very rapidly? This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved. ''' Having a calendar of the breaking changes already planned like explain in the video seems dubious. And about Chrome, Chrome is an implementation not a spec, Angular is both an implementation and a spec. Do you really want a JavaScript 55 ?
  - the_duke 10y ago
    ECMAScript in their eternal wisdom have decided to do a yearly release of the spec with incremental updates. So if they keep on track, JavaScript 55 will be here in 2055. ;)
    - tannhaeuser 10y ago
      Yeah, I don't understand it either. Why do they setup themselves (and their users) to that kind of "march of progress"? They should target features that are in real demand rather than regularly put out what they have. Perhaps they do it because of job security?
    - elros 10y ago
      I think, technically, in 2064 :P
  - c17r 10y ago
    Funny you should be 55 as a number. My Chrome version is currently 55.0.2883.95
paulddraper 10y ago
Chrome updates its major version every 6 weeks. Do you have browser fatigue?
- taeric 10y ago
  Actually... Yes. Browsers have introduced as many vulnerabilities as they have cleared, it often seems.
- manquer 10y ago
  I don't write code for the browser I write for ecmascript 5/6, HTML 5 , CSS 3 if those standards kept changing every 2 months then yes.
chrisan 10y ago
I don't think the problem is with semver. That has a very clear goal of describing MAJOR.MINOR.PATCH changes where MAJOR is a version increase when you make incompatible API changes. semver is merely describing the results of your changes. If you hate anything, it should be Angular for they decide when they are going to introduce incompatible changes.
mmgutz 10y ago
Semver has bitten us several times with node packages. All most of us care about is whether a release is backwards compatible with the package we developed against. There should be one rule: if it's the same major version it is compatible. We lock all package versions now negating the benefits of semver.
- deleted 10y ago
  [deleted]
- majewsky 10y ago
  Exactly. I always say that, if I ever design my own programming language with a central package repository, I will build the repo such that it downright refuses to publish minor version updates that break the API (or patch updates that change the API).
skybrian 10y ago
Semver (or really, the concept of a single unified version number) makes it difficult to compare small versus large projects. Large projects have less information in the version number. Let's say you have N small projects, each of which gets a major version bump once every two years. Now, combine them into a single umbrella project. If you have 24 of them and they don't coordinate, you'll end up bumping the major version once a month (on average), even though the code didn't really change any more than before. To somewhat improve on this, you can coordinate release dates, and you get a regular major version bump, the times when it's always true that some things changed, even though most things didn't. Either way, the version bump itself doesn't tell you as much compared to having separate projects.

pfooti 10y ago

I dunno. I use hapijs at my day job (and am .. happy .. with it). They're on like version 16.0 so far, but I tend to only actually bump my own installed version every now and again. We basically update if there's a bug we need addressing or whenever it's time to update all our dependencies. Sometimes there's a breaking change we need to work through (often in the plugin ecosystem with stuff like bell for oauth integration), but usually the major changes aren't too painful to transition through. It's still nice to use semver and know what to expect. You just have to get acclimatized to having very large major version numbers. I mean, Chrome is up to version what, 55?

uncle_joe 10y ago
Here is an except of the FAQ of semver ''' If even the tiniest backwards incompatible changes to the public API require a major version bump, won’t I end up at version 42.0.0 very rapidly? This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved. ''' Having a calendar of the breaking changes already planned like explain in the video seems dubious. And about Chrome, Chrome is an implementation not a spec, Angular is both an implementation and a spec. Do you really want a JavaScript 55 ?
- the_duke 10y ago
  ECMAScript in their eternal wisdom have decided to do a yearly release of the spec with incremental updates. So if they keep on track, JavaScript 55 will be here in 2055. ;)
  - tannhaeuser 10y ago
    Yeah, I don't understand it either. Why do they setup themselves (and their users) to that kind of "march of progress"? They should target features that are in real demand rather than regularly put out what they have. Perhaps they do it because of job security?
  - elros 10y ago
    I think, technically, in 2064 :P
- c17r 10y ago
  Funny you should be 55 as a number. My Chrome version is currently 55.0.2883.95

paulddraper 10y ago

Chrome updates its major version every 6 weeks. Do you have browser fatigue?

taeric 10y ago
Actually... Yes. Browsers have introduced as many vulnerabilities as they have cleared, it often seems.
manquer 10y ago
I don't write code for the browser I write for ecmascript 5/6, HTML 5 , CSS 3 if those standards kept changing every 2 months then yes.

chrisan 10y ago

I don't think the problem is with semver. That has a very clear goal of describing MAJOR.MINOR.PATCH changes where MAJOR is a version increase when you make incompatible API changes. semver is merely describing the results of your changes. If you hate anything, it should be Angular for they decide when they are going to introduce incompatible changes.

mmgutz 10y ago

Semver has bitten us several times with node packages. All most of us care about is whether a release is backwards compatible with the package we developed against. There should be one rule: if it's the same major version it is compatible. We lock all package versions now negating the benefits of semver.

deleted 10y ago
[deleted]
majewsky 10y ago
Exactly. I always say that, if I ever design my own programming language with a central package repository, I will build the repo such that it downright refuses to publish minor version updates that break the API (or patch updates that change the API).

skybrian 10y ago

Semver (or really, the concept of a single unified version number) makes it difficult to compare small versus large projects. Large projects have less information in the version number. Let's say you have N small projects, each of which gets a major version bump once every two years. Now, combine them into a single umbrella project. If you have 24 of them and they don't coordinate, you'll end up bumping the major version once a month (on average), even though the code didn't really change any more than before. To somewhat improve on this, you can coordinate release dates, and you get a regular major version bump, the times when it's always true that some things changed, even though most things didn't. Either way, the version bump itself doesn't tell you as much compared to having separate projects.