3 ms·

>for example this javascript will run in Chrome for all Chrome > build xyz? It was simpler (not saying better, just simpler) to V2.5 or later supports this On

>for example this javascript will run in Chrome for all Chrome > build xyz? It was simpler (not saying better, just simpler) to V2.5 or later supports this On a related note, a few years ago I went from assigning version numbers to the releases of some of my projects to simple date-based versions (e.g., "version 20130307"). One of the reasons I switched to using dates is that beyond v1.0 it's often hard to assign versions to software in a meaningful fashion (is our next release a "v3.0" or a "v2.1"?); that is especially true if your software isn't of the commercial variety where a major version increase hinges on the question of "is this substantially different to charge an upgrade fee of $N for?". One exception to this naming rule is that I assign low numerical versions (e.g., "v0.03") to early code to indicate its quality. What would you say about this practice vs. build numbers or traditional version numbers? Edit: To clarify, I don't think this alone constitutes going rolling release. Overall, I found it pleasant to not have to think about version numbering. Release dates also seem to be easier to remember and interpret than mere build numbers (a half-forgotten date like "201207..." is easier to pin down than "build 12573... something")

qznc 14y ago
Use http://semver.org/ http://semver.org/ it provide clear semantics on how to increase version numbers.
ChuckMcM 14y ago
Well, I've grown up with semantic version numbers. In those there was a document somewhere that described exactly what the version numbers "meant" in terms of compatibility. So Major.minor,sub-minor was the most common, the policy there was : * major number change, may have incompatible changes with APIs. Applications depending on a major number won't be compatible with the previous version of the library. * minor number change, changes by 'addition' only, no changes to existing code necessary, backward compatibility testing advised. * sub-minor number change. No semantic changes, bugs and other defects fixed, some workarounds may no longer be needed. With rolling releases it seems the only safe thing you can assume is that no earlier release is compatible and later releases are probably compatible. That seems like a step backward.

qznc 14y ago

Use http://semver.org/ http://semver.org/ it provide clear semantics on how to increase version numbers.

ChuckMcM 14y ago

Well, I've grown up with semantic version numbers. In those there was a document somewhere that described exactly what the version numbers "meant" in terms of compatibility. So Major.minor,sub-minor was the most common, the policy there was : * major number change, may have incompatible changes with APIs. Applications depending on a major number won't be compatible with the previous version of the library. * minor number change, changes by 'addition' only, no changes to existing code necessary, backward compatibility testing advised. * sub-minor number change. No semantic changes, bugs and other defects fixed, some workarounds may no longer be needed. With rolling releases it seems the only safe thing you can assume is that no earlier release is compatible and later releases are probably compatible. That seems like a step backward.