3 ms·

I think the TeX and METAFONT versioning system is my favorite versioning system. It's just wonderful. For those of us working on things not worthy of a mathema

I think the TeX and METAFONT versioning system is my favorite versioning system. It's just wonderful. For those of us working on things not worthy of a mathematical constant, I prefer plain old major.minor. If it breaks something, increment major and reset minor to 0. Anything else doesn't really matter.

pixelcort 6y ago
http://www.ntg.nl/maps/05/34.pdf http://www.ntg.nl/maps/05/34.pdf
BerislavLopac 6y ago
You mean comver? https://gitlab.com/staltz/comver https://gitlab.com/staltz/comver
- slx26 6y ago
  I mean, a few numbers can't convey everything that's relevant for releases. But I like how comver explains well some of the concepts. I expand with a few more: - Is the release stable? Alpha, beta, experimental new features? - Does the release have known vulnerabilities? How insecure is it? (of course, this changes as time passes and might stop being tracked, so it's not easy to manage) - Did a new release break back-compatibility? How much? Are we breaking everything, or just slightly changing the behavior of one function? - Does the release include new important features or API changes? - How often should I check for new releases, or how can I get notified if there are important unexpected changes? To me, any non-toy software project needs to respond very clearly to all these questions. If it does, I don't care about semver or not semver. If it doesn't, I don't care about semver or not semver.
- benjaminjosephw 6y ago
  SemVer says that a PATCH can only include backwards compatible changes which fix incorrect behavior. Less important is whether or not a bug has been fixed but whether anything other that internal behavior has changed. MAJOR versions can also be incremented when "substantial new functionality or improvements are introduced within the private code" which is really the cause for confusion and, in my opinion, should be removed from the SemVer standard. There's no semantic value to consumers when significant amounts of private code has changed except for the potentially heightened possibility of introducing bugs. Removing this would clear the confusion up altogether. But the ComVer contention is that bugs don't deserve special treatment. I disagree. Changes to behavior that fix something but don't change anything else are changes I'm likely to want to deploy while maintaining a system. I might be using a legacy version where the main branch has progressed but I still want to deploy PATCH releases for bug fixes for an older version when they become available. I do not want to upgrade by a MINOR version if I can avoid it because it would add functionality or interfaces I don't need and which themselves could be problematic. I want to make as little change as necessary to maintain a otherwise stable system. Minimizing the surface area of a release to only the necessary is an important principle to follow when publishing public APIs. Thinking about bug fixes as distinct from new features means you're considering every change in light of the potential impact to consumers. Even when know you don't have any actual dependent consumers, it's still a good habit of a disciplined engineer.
  - BerislavLopac 6y ago
    My general approach is to look at the unit (and possibly integration) tests: if the new release has no changes in test code, that's a PATCH release. Of course it's not clear cut and can't really be automated, but as a guiding point it has served me well.
  - benjaminjosephw 6y ago
    Edit: It should read "MINOR versions can also be incremented when..." instead of MAJOR.

pixelcort 6y ago

http://www.ntg.nl/maps/05/34.pdf http://www.ntg.nl/maps/05/34.pdf

BerislavLopac 6y ago

You mean comver? https://gitlab.com/staltz/comver https://gitlab.com/staltz/comver

slx26 6y ago
I mean, a few numbers can't convey everything that's relevant for releases. But I like how comver explains well some of the concepts. I expand with a few more: - Is the release stable? Alpha, beta, experimental new features? - Does the release have known vulnerabilities? How insecure is it? (of course, this changes as time passes and might stop being tracked, so it's not easy to manage) - Did a new release break back-compatibility? How much? Are we breaking everything, or just slightly changing the behavior of one function? - Does the release include new important features or API changes? - How often should I check for new releases, or how can I get notified if there are important unexpected changes? To me, any non-toy software project needs to respond very clearly to all these questions. If it does, I don't care about semver or not semver. If it doesn't, I don't care about semver or not semver.
benjaminjosephw 6y ago
SemVer says that a PATCH can only include backwards compatible changes which fix incorrect behavior. Less important is whether or not a bug has been fixed but whether anything other that internal behavior has changed. MAJOR versions can also be incremented when "substantial new functionality or improvements are introduced within the private code" which is really the cause for confusion and, in my opinion, should be removed from the SemVer standard. There's no semantic value to consumers when significant amounts of private code has changed except for the potentially heightened possibility of introducing bugs. Removing this would clear the confusion up altogether. But the ComVer contention is that bugs don't deserve special treatment. I disagree. Changes to behavior that fix something but don't change anything else are changes I'm likely to want to deploy while maintaining a system. I might be using a legacy version where the main branch has progressed but I still want to deploy PATCH releases for bug fixes for an older version when they become available. I do not want to upgrade by a MINOR version if I can avoid it because it would add functionality or interfaces I don't need and which themselves could be problematic. I want to make as little change as necessary to maintain a otherwise stable system. Minimizing the surface area of a release to only the necessary is an important principle to follow when publishing public APIs. Thinking about bug fixes as distinct from new features means you're considering every change in light of the potential impact to consumers. Even when know you don't have any actual dependent consumers, it's still a good habit of a disciplined engineer.
- BerislavLopac 6y ago
  My general approach is to look at the unit (and possibly integration) tests: if the new release has no changes in test code, that's a PATCH release. Of course it's not clear cut and can't really be automated, but as a guiding point it has served me well.
- benjaminjosephw 6y ago
  Edit: It should read "MINOR versions can also be incremented when..." instead of MAJOR.