3 ms·

Chromes versioning does not make any sense; do they have 60 breaking changes?

CamelCaseName 9y ago
Yes. https://en.wikipedia.org/wiki/Google_Chrome_version_history https://en.wikipedia.org/wiki/Google_Chrome_version_history
- benmarten 9y ago
  Looking at the changes in 59; doesn’t seem any breaking change to me rather than features It just seems ridiculous to me to have 4 major releases in ‘17 alone
  - charrondev 9y ago
    If understand they do it on a schedule. A new major release every 6 weeks. Dev bumps to beta, beta bumps to stable, and the old stable is retired.
  - colemickens 9y ago
    >It just seems ridiculous to me to have 4 major releases in ‘17 alone Hm, why is that ridiculous? Do you just mean in terms of having "breaking changes" every 3 months? I guess I've never heard of someone bit by this... they'd have to be going out of their way to force a downgrade to trigger breakage from this, no?
DiabloD3 9y ago
Major number is incremented when any user facing data or setting changes (ie, ~/.chrome might not be backwards compatible anymore 100% safely). Minor number is incremented whenever. The number that is most important is the third number, the four digit build number, which increments monotonically and never resets. That is a more meaningful number than the first two, IMO anyways.
sowbug 9y ago
It's really simple. The first number increments when a new release branch is cut off master, about every 6 weeks. The second is always zero. The third is a build number, which is an incrementing global. There were exceptions in the early days when the team was still figuring things out. For example, release-branches were cut more sporadically, and the middle number was used to sorta-kinda represent smaller feature changes. You might be thinking of release dates tied to a set of completed product features. Chrome doesn't work that way. The team ships on a regular schedule, holding back features that aren't ready for the public. Frequent releases help mitigate the urge for individual teams to ship low-quality stuff just because the next release train was a long and/or unpredictable time in the future.
dbbk 9y ago
No, Chrome is not semver. Also there should be no breaking changes according to web standards.

Yes. https://en.wikipedia.org/wiki/Google_Chrome_version_history https://en.wikipedia.org/wiki/Google_Chrome_version_history

benmarten 9y ago
Looking at the changes in 59; doesn’t seem any breaking change to me rather than features It just seems ridiculous to me to have 4 major releases in ‘17 alone
- charrondev 9y ago
  If understand they do it on a schedule. A new major release every 6 weeks. Dev bumps to beta, beta bumps to stable, and the old stable is retired.
- colemickens 9y ago
  >It just seems ridiculous to me to have 4 major releases in ‘17 alone Hm, why is that ridiculous? Do you just mean in terms of having "breaking changes" every 3 months? I guess I've never heard of someone bit by this... they'd have to be going out of their way to force a downgrade to trigger breakage from this, no?

DiabloD3 9y ago

Major number is incremented when any user facing data or setting changes (ie, ~/.chrome might not be backwards compatible anymore 100% safely). Minor number is incremented whenever. The number that is most important is the third number, the four digit build number, which increments monotonically and never resets. That is a more meaningful number than the first two, IMO anyways.

sowbug 9y ago

It's really simple. The first number increments when a new release branch is cut off master, about every 6 weeks. The second is always zero. The third is a build number, which is an incrementing global. There were exceptions in the early days when the team was still figuring things out. For example, release-branches were cut more sporadically, and the middle number was used to sorta-kinda represent smaller feature changes. You might be thinking of release dates tied to a set of completed product features. Chrome doesn't work that way. The team ships on a regular schedule, holding back features that aren't ready for the public. Frequent releases help mitigate the urge for individual teams to ship low-quality stuff just because the next release train was a long and/or unpredictable time in the future.

dbbk 9y ago

No, Chrome is not semver. Also there should be no breaking changes according to web standards.