3 ms·

> it simplifies versioning. there is no more major and minor versions. there is just version. Yep. For developers that build software its very easy. Fixed a bu

by deely3 3y ago

> it simplifies versioning. there is no more major and minor versions. there is just version. Yep. For developers that build software its very easy. Fixed a bug - version++, improved performance - version++, changed API - yes version++, rewrite program in another language, broke all compatibility, remove 2/3 of all supported features, yep, version++. By your logic difference between bugfix in programming language and change of syntax should be indicated with the same version++?

em-bee 3y ago
no, i only don't see the need to distinguish between major and minor feature releases. there are feature releases and bugfix releases. this is what the linux kernel, browsers and even some linux distributions are doing. for most apps but also for the linux kernel and for programming languages incompatible changes should not even happen. a browser should support old websites, so there is never an excuse to break compatibility. hence no need for versioning that. i am not talking about libraries and interfaces. the main problem with major.minor versions is that it is never clear what should be a major version change and what should not. emacs solved the problem by simply dropping the major version. a few other applications did too. the pike programming language switched from 0.6 to 7, avoiding calling it 1.0 as the language had already been stable for some time by then. then they slowly increased the minor version to 7.8 in 2008, but where afraid to go to 8.0. i remarked that if they didn't switch to 8 soon, they never would. eventually they switched to 8.0, 5 years later, and are now at 8.0.1738. (but there is a 9.0.0 version in the development branch since end of last year). sbcl switched from 1.5.9 to 2.0.0 without any major changes. since then they release a new version every month and the version number is basically decade.year.month. there is no distinction between major and minor versions. the current version (looking at the calendar) should be 2.3.7. what does that tell me about the difference to 2.2.11? absolutely nothing. if they used a single linear increasing version it would not make a difference. which in my eyes is actually correct for both examples because a programming language should not have major changes. the python2->3 transition was a big headache. it should not have been necessary. in most examples that i can find the distinction between major and minor is meaningless. a more sensible distinction is: feature.bugfix, that's enough. and for many apps i would not even bother with bugfix releases unless the bugs are damaging to the users.

by deely3 3y ago

em-bee 3y ago

no, i only don't see the need to distinguish between major and minor feature releases. there are feature releases and bugfix releases. this is what the linux kernel, browsers and even some linux distributions are doing. for most apps but also for the linux kernel and for programming languages incompatible changes should not even happen. a browser should support old websites, so there is never an excuse to break compatibility. hence no need for versioning that. i am not talking about libraries and interfaces. the main problem with major.minor versions is that it is never clear what should be a major version change and what should not. emacs solved the problem by simply dropping the major version. a few other applications did too. the pike programming language switched from 0.6 to 7, avoiding calling it 1.0 as the language had already been stable for some time by then. then they slowly increased the minor version to 7.8 in 2008, but where afraid to go to 8.0. i remarked that if they didn't switch to 8 soon, they never would. eventually they switched to 8.0, 5 years later, and are now at 8.0.1738. (but there is a 9.0.0 version in the development branch since end of last year). sbcl switched from 1.5.9 to 2.0.0 without any major changes. since then they release a new version every month and the version number is basically decade.year.month. there is no distinction between major and minor versions. the current version (looking at the calendar) should be 2.3.7. what does that tell me about the difference to 2.2.11? absolutely nothing. if they used a single linear increasing version it would not make a difference. which in my eyes is actually correct for both examples because a programming language should not have major changes. the python2->3 transition was a big headache. it should not have been necessary. in most examples that i can find the distinction between major and minor is meaningless. a more sensible distinction is: feature.bugfix, that's enough. and for many apps i would not even bother with bugfix releases unless the bugs are damaging to the users.