When browsing the packagist.org repositories you see packages with these version numbers e.g. If you look at the Phpunit repo
There are a few instances
4.5.x-dev
4.3.x-dev
4.2.x-dev
Do these packages contain the current work the developers are performing towards basic updates, security and bugfixes etc on an otherwise basically stable package?
These are the dev branches. These are unstable and contain bug fixes, etc. This will eventually be released as 4.5.8 for instance (if the library is still supported).
You can get it by using 4.5.x-dev or 4.5.*#dev as version constraint.
Related
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.
We build our installs\releases using Install Shield. I have come to a situation where we have a patch that cannot be upgraded by a release with a higher version number, that is missing components included in the patch.
After releasing a full minor release (i.e. 7.2.0) we released a patch on a previous full minor release (i.e. 7.1.12).
The Patch 7.1.12 had files and components added that do not exist in 7.2.0. The patch is not uninstallable.
It is now impossible to upgrade 7.1.12 to 7.2.0 because of the missing components. Some customers specifically want to upgrade to 7.2.0 and not a later version (7.3.0) where the components can be added to fix the issue.
Short of uninstalling 7.1.12 and then installing 7.2.0 I couldn’t find any solution to fix.
Is there any way around this? Can we build a 7.1.13 as a bridge to somehow fix the mistake. Or use an argument when installing 7.2.0 to get around this.
I looked around the registry and I am trying to figure out if it is possible to remove the components through the registry.
I tried deleting the component entries in the registry. that didn't do it.
If I delete the product entry in the registry that works - but it must be overkill.
I also tried deleting the patch msi from C:\Windows\Installer but that didn't do it.
There must still be a way to unlink the component from the feature in the registry without deleting the entire product.
It sounds like you're trying to do a series of Minor Upgrades, with at least 7.1.12 delivered as a patch. Using minor upgrades imposes various limitations; anything that requires you to Change the Product Code must be avoided. In your case, note that adding components is allowed, but not the reverse:
The update can add a new component to a new or an existing feature.
The product code must be changed if any of the following are true for the update:
A component is removed from an existing feature.
In short, any modifications to the feature-component tree, other than the addition of new ones, is going to require changing the product code, and thus a Major Upgrade. Major upgrades perform an uninstallation behind the scenes, and thus are less restrictive about the changes they are allowed to deliver.
You have two options:
Use a major upgrade, or some other means of uninstalling the old installation before installing the new version. If possible, this is what I would recommend. Using minor upgrades often adds more difficulty than benefit (though your needs may differ).
Maintain the new components in your newer versions. Note that you do not necessarily have to maintain the resources within them:
The update can add, remove, or modify the files, registry keys, or shortcuts of components that are not shared by two or more features.
But you will have to make additional changes to account for the changes to the resources. In your case, this probably will require additions to the RemoveFile table, and may be best served by "puncture component" pattern.
Spelunking through the registry for a workaround that modifies Windows Installer's bookkeeping is a bad idea. It may work, it may appear to work, or it may not work at all. In no case is it supported.
If both versions 7.1.12 and 7.2.0 are already publicly released, you're in a rough spot. I think your best bet there is to re-release 7.2.0 with a new product code and version, e.g. a 7.2.1 major upgrade. You can advise your end users that those already at 7.2.0 don't need to install it.
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.
I am working on a SaaS application with node.js using npm for managing dependencies. I am trying to decide what to do about the version number. Our release model will be to market features and release when ready, rather than marketing versions.
I am looking for advice on the version field for package.json. Since we won't be publishing the app to the npm registry, I can really use whatever version number I want. I really don't want to maintain a typical version number like 1.0, 1.2, 2.0, etc. Since a release is simply a project that ships when ready, dates make better versions for me, like "RELEASE_20130104", but npm requires that the version field in package.json be parseable by semver rules.
I am interested in hearing what the rest of the community has done for SaaS npm-based apps.
Requirements:
Effortless - I don't want to waste time debating between 1.2.0 or 2.0. It's just the next release.
Must satisfy the npm version syntax rules.
Nice-to-haves:
Scriptable through a build process, like extracting SVN branch and
revision number.
Version means something, like the release date.
Solutions I have come up with:
Strictly follow semver major.minor.patch pattern. This will require separate scripts for different release types and will be a nightmare for pre-release builds.
Express the release date in semver format like "2013.01.04"
SVN revision number + branch or tag name like "21484-BugFix21". Downside there is that non-release builds' versions don't tell you what release version they are branched from.
Pick a dummy version and never change it like "1.0.0". Track the version in the format I want in a separate field, like "appRelease": "2013.01.04".
I don't expect right or wrong answers. There are a ton of solutions. I am looking to see what approaches others have taken in the past.