Semantic versioning brings the follow approach:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backwards-compatible manner
PATCH version when you make backwards-compatible bug fixes
However a frontend project doesn't have an API, its doesn't break compatibility of usage, then, what the arguments to change the versions in frontends?
Please, sugestions.
Proposal
Given the importance of the installation-requirements of an application to installer-users, I propose that semver be used to version end-user applications using the installation-requirements as the public API with installer-users as the consumers of this API.
In practice, increment the:
• MAJOR version when you make incompatible API changes (e.g. installer-users have to modify their infrastructure (phone/tablet/PC/web-server/firewall config/etc) in some way),
• MINOR version when you add functionality in a backwards-compatible manner (e.g. passing additional data to an already-provisioned API or adding any end-user functionality that does not affect the installation-requirements), and
• PATCH version when you make backwards-compatible bug fixes (e.g. fixing any end-user bug that does not affect the installation requirements).
By treating the installer-users as the consumers of an end-user application, and the installation-requirements as the public API, I believe that semver does make sense and is valuable as a communications mechanism for end-user applications.
https://medium.com/#u_glow/making-sense-of-semantic-versioning-for-end-user-software-applications-a3049d97478b
Related
Can I simply replace log4j-core-2.x (e.g. 2.8.2) with 2.17.1 without breaking backward compatibility? In other words, is Log4j project following Semantic Versioning?
Log4J official changelog does not provide any clear statement on that. But this would be a dramatic simplification in the remediation process.
Bonus question: is this also true for log4j-api-2.x?
There has been some API breakage in log4j-core, so it is not strictly semantically versioned. The only one I am aware of is:
The ConfigurationFactory#getConfiguration methods got an additional LoggerContext parameter (see LOG4J2-1547). This can prevent a Log4j upgrade in old Spring Boot 1.2.x versions (see this question).
However, this might be the only exception to semantic versioning, so you should upgrade the library and see if everything works.
What is the policy when one enforces a newer (Node.js) engine version?
Is it semver MAJOR or semver MINOR?
Context: I'm the author of a package with 2k stars on github (30k downloads per week) and I recently enforced Node.js v14 (because I'm starting to use optional chaining and null coalescing everywhere), and made it a new MINOR version.
But some of my users are complaining and asking me to make that change a new MAJOR version.
Also previously, nobody complained when I enforced Node.js v10 on a MINOR version.
I can't find any resource about that matter, even the semver spec does not specify this (not even in the FAQ section). The spec only talks about the API.
I want to keep my project in line with the correct policy.
Quoting Isaacs from Twitter (#izs), author of the semver npm package (and by the way founder of npm):
I've always considered SemVer Major to mean "you will have to change something on your end to start using this update".
If the previous version worked on platform version X, and the new version requires platform version X+n, then that qualifies, yes.
This has been discussed here in many threads as well SemVer discusions. Some claim it is subjective, but I think if you were to replace the opinionated terms (API, Package, Product) with something like OBV (Object Being Versioned), you will see that spec and most of the knowledgeable participants agree with each other.
If your customer's build environment is broken because you issued a minor or patch release, they have every right to complain. The SemVer spec really focuses more on API versioning, than packages, though it does mention the later in a few places. So the key here is, most of us never actually version just an API, we version packages and the manifests within them, which also implicitly/explicitly include transitive dependencies.
The whole point of SemVer is to communicate risks to consumers of those OBV's. As a publisher, you are responsible for the entire dependency tree that you include in your OBV's. You can chose whether to implicitly or explicitly introduce a breaking transitive dependency into your OBV, therefore it is your responsibility to inform your customers of the risk by bumping the major version.
On the website of Debian, it's written about point releases:
They usually incorporate the security fixes released until the time of
the update and fixes for grave bugs in the current release.
If I correctly understand, that means only minor updates can occur in the packages of the current stable version, right?
In other words, I want to know if a binary who depends of a library in a specific version (libmicrohttpd.so.12 for instance) will stay compatible in the next point releases of Debian.
Yes, but it is very seldom.
In general you are right, the point releases should not change existing API and ABI.
But there could be problems on doing that: security changes would require a lot of work, and upstream will do only for the new version. In such cases the version will be dump. But this is very seldom: it would need a security bug which effect the fundamental design of a library (not just some coding error).
In any case the old version will remain on archives, and you can keep it (so that it would not be automatically removed), so that you can still use, hopefully with relevant safe guard.
I have an API server built with loopback.io (NodeJS) version 3.0.0, however latest version is 3.17.1 and there obviously have been a lot of security and bug fixes over all this time, which makes me feel on potential danger and outdated.
How can I update the framework without affecting my own code? How do other frameworks deal with this kind of issue?
Your code should be completely separate from the loopback.io code. As such, you should be able to do npm update looback.io from the right directory and it should update the loopback.io code and not affect your code at all.
Now this assumes you were using loopback.io as a library that you loaded with require() and that you did not modify the actual loopback.io code yourself in any way.
Before upgrading, you will want to examine the release notes for the revisions of loopback.io since the version you originally installed and make sure there are only bug fixes and no compatibility issues with code written for prior versions (e.g. API changes, etc...). If there are any API changes or "breaking" fixes, then you may have to slightly modify your code in that one area to update to the new API.
Then, after upgrading, run your unit tests to see if everything is still working as you would expect.
Are there any plans for the ServiceStack packages to start using the SemVer standard? We just had an unfortunate circumstance where we were broken by the interface breaking changes introduced in 4.0.44 from 4.0.43 around OrmLite.
We are a sizable commercial customer and have a custom implementation of a OrmLiteDialectProvider for one of our DBMSs, it all seemed good upon the initial upgrade in our web application, however as part of testing the changes around type converting broke our system. This wasn't initially evident as part of the upgrade because our custom implementation is in a NuGet package which overrides OrmLiteDialectProvider.ConvertDbValue on version 4.0.38 which is now gone. There were no binding issues because it is only a minor version difference.
NuGet adopted SemVer back in version 1.6.
Having the SemVer standard would make it a lot easier for us to know when interface breaking changes have been made, without having to dig through the Release Notes page.
NOTE: The release also didn't indicate that the old method had been removed and upgrading would break any custom implementations.
UPDATE FROM RESPONSE
Anyway, fair enough answer. I can appreciate it would be difficult to track each package individually. In our case we wrote a custom dialect provider as we have a legacy DBMS that wasn't supported and this appeared to be the way we were supposed to add the support. We wanted to use ORMLite because we use the rest of ServiceStack and it's a fantastic product.
The new way to support the types is a great improvement and actually made our implementation easier.
We actually ran into this issue because we do always keep our ServiceStack packages inline and were upgrading the ASP portion for some fixes to the WSDL generation and this came along as part of our upgrade.
ServiceStack adopts a single rolling version for all NuGet packages which all share the same Version number. Of all ServiceStack's 60 NuGet packages it's likely there's a breaking change to at least one of the packages so semver would be useless, you should also never mix and match different versions of ServiceStack together - when you upgrade, upgrade all packages to reference the same package versions. We do aim to keep user-facing breaking changes to a minimum, by looking to deprecate old API's first, maintain parallel API versions for a while then list the new API's release notes.
IOrmLiteDialectProvider is not a user-facing interface
However IOrmLiteDialectProvider is not considered a user-facing interface since it should be extremely rare that anyone implements their own custom provider. It's also the interface for specialization for all RDBMS's and often changes with every release to support new features, internal refactoring, optimizations, etc. E.g. implementing Type Converters was a major internal refactor that required changes to IOrmLiteDialectProvider but did not affect OrmLite's external user-facing API, later releases includes optimizations requiring further changes, again this doesn't affect OrmLite's external user-facing API.
SemVer won't help here, every ServiceStack version potentially has a breaking change in some of the packages and we have no intention to complicate each release by versioning each of the individual packages differently. The issue you're having is depending on an unstable Interface that's not intended for customization. It's not treated as a user-facing API so we don't try to maintain compatibility with existing versions or publish breaking changes which happens nearly every time we add features / optimizations to OrmLite. You should instead check the commit history of
IOrmLiteDialectProvider for any changes to this interface.