4 ms·

I think the big problem with semver is point 2 in their summary: "MINOR version when you add functionality in a backwards-compatible manner" That may make sen

I think the big problem with semver is point 2 in their summary: "MINOR version when you add functionality in a backwards-compatible manner" That may make sense for very large software projects or operating systems where backwards compatibility is a huge concern, but it's not a good fit for the majority of software projects. This is especially true when these projects aren't compiled and thus don't even have an ABI to worry about. This view on versioning I think comes from a time when most software was compiled and when compiling that software would take a _long_ time or require downtime; thus protecting ABI compatibility was worth the effort. For modern projects that are in an interpreted language, I think constraining the middle version number to "non-breaking" changes is silly as it's copying a concern that no longer applies. It forces you to choose between "bug-fix" and "feature" releases and pace your project development in a rigid fashion that may not make much sense. Also, I think it's ridiculous to require anything other than big-fix releases to be non-breaking in the first place. If 1.6.x worked for you, why are you even trying to use 1.7.x if not to access new features? If that's the case, you're going to be editing your code again anyways. Worrying about a release manager automatically pulling a 1.7 codebase to upgrade a 1.6 codebase is silly; why is the package manager doing this in the first place?

goldfeld 12y ago
Having both MINOR and PATCH to mean non-breaking changes really seems excessive and based on very large waterfall-based software projects, because for most open source development it's completely arbitrary whether to bump patch or minor. I think it would be far more useful to have both MAJOR and MINOR to signify breaking changes (with MAJOR being close to the romantic versioning that Jeremy alludes to, where the software effectively enters a new phase.) And a number like 1.7.247 is more intelligible than 170.2.5, and really, if you're the rare monolithic long release-cycle software project, just use an extra number after PATCH. It's not like there'd be an acute concern over the verboseness of that version number internally compared to all the other highly bureaucratic processes going on in the organization.
- dllthomas 12y ago
  I interpret PATCH as "no change in the intended semantics, just a bug fix". Occasionally that's still ambiguous, when the bug was in the intended semantics, but I'm not sure that's a big problem. When adding new functionality, I prefer to see MINOR bumped, even if small. Just one opinion, of course.

goldfeld 12y ago

Having both MINOR and PATCH to mean non-breaking changes really seems excessive and based on very large waterfall-based software projects, because for most open source development it's completely arbitrary whether to bump patch or minor. I think it would be far more useful to have both MAJOR and MINOR to signify breaking changes (with MAJOR being close to the romantic versioning that Jeremy alludes to, where the software effectively enters a new phase.) And a number like 1.7.247 is more intelligible than 170.2.5, and really, if you're the rare monolithic long release-cycle software project, just use an extra number after PATCH. It's not like there'd be an acute concern over the verboseness of that version number internally compared to all the other highly bureaucratic processes going on in the organization.

dllthomas 12y ago
I interpret PATCH as "no change in the intended semantics, just a bug fix". Occasionally that's still ambiguous, when the bug was in the intended semantics, but I'm not sure that's a big problem. When adding new functionality, I prefer to see MINOR bumped, even if small. Just one opinion, of course.