3 ms·

Maybe people are looking wrong at Chrome version numbering. Take GNU Emacs for instance. At some point the developers realized that their software would never b

by p4bl0 15y ago

Maybe people are looking wrong at Chrome version numbering. Take GNU Emacs for instance. At some point the developers realized that their software would never be the subject of a change in nature big enough to change the major version number, so they ditched it. Now we have Emacs 23 but it's actually Emacs 1.23, and nobody complains. I think it's really a non-issue and it's not really worth talking about: Chrome just doesn't display the '1.' (or '0.' depending on your view point ^^) in front of its version number :-).

dkersten 15y ago
Yeah, its more a release number. It makes sense to use a single positive integer and simply increment it every release. Having said that, though, I quite like Semantic Versioning[1]. The advantage it has over a single incrementing counter is that you know when API compatibility changes. [1] http://semver.org/ http://semver.org/
- chalst 15y ago
  Right. Think of a new version of some software that drops support for a deprecated part of an API in a minor release. I did get screwed by that happening with a Latex package, xy-pic, some years back.
  - dkersten 15y ago
    Yeah. Painful. Thats the kind of thing semantic versioning aims to solve: within a major release, all minor and patch releases must maintain backwards compatibility. Patch releases may not change the API at all; minor releases may add to it but not remove things[1]. Major releases may drop backwards compatibility by removing or modifying API items. Seems like a reasonable system to me and would avoid the problem you mentioned. [1] I guess it can deprecate things, as long as they are still available for use.
- user24 15y ago
  Semantic Versioning looks like a really nice solution. At the moment our internal versioning philosophy is A.C.F - adding.changing.fixing but I can see that something more robust has its uses.

by p4bl0 15y ago

dkersten 15y ago

Yeah, its more a release number. It makes sense to use a single positive integer and simply increment it every release. Having said that, though, I quite like Semantic Versioning[1]. The advantage it has over a single incrementing counter is that you know when API compatibility changes. [1] http://semver.org/ http://semver.org/

chalst 15y ago
Right. Think of a new version of some software that drops support for a deprecated part of an API in a minor release. I did get screwed by that happening with a Latex package, xy-pic, some years back.
- dkersten 15y ago
  Yeah. Painful. Thats the kind of thing semantic versioning aims to solve: within a major release, all minor and patch releases must maintain backwards compatibility. Patch releases may not change the API at all; minor releases may add to it but not remove things[1]. Major releases may drop backwards compatibility by removing or modifying API items. Seems like a reasonable system to me and would avoid the problem you mentioned. [1] I guess it can deprecate things, as long as they are still available for use.
user24 15y ago
Semantic Versioning looks like a really nice solution. At the moment our internal versioning philosophy is A.C.F - adding.changing.fixing but I can see that something more robust has its uses.