I'm making an npm package and I published it as version 1.0.0 because I was happy with the public API. But now, I'm in the process of adding an "examples" subproject to showcase how to use the library. Obviously, I won't publish the example project as a part of the library (it will be added in .npmignore), but it will be on my github repo. Is there any semantic versioning rules for that? Should I update the patch version, minor version or nothing at all?
On one hand, I think I shouldn't update the version since it won't be published to npm, therefore normal users of the app won't even notice a difference in the package. On the other hand, semver rules say you should update the "patch" or "minor" version when you make documentation changes, even though the documentation isn't published either.
The relevant spec here is #3:
Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.
Since nothing was added to your API and it's obviously not a breaking change, you should bump the patch number.
Related
I've developed a composer package that's included into many Github repo Laravel projects. It's set to a specific version, but even if I make it slightly looser and set the patch version to be a asterisk for the patch version I still need to run a composer update in the project that requires the package so that when running composer install on a server it installs the correct version.
The issue I'm facing is that when I release a new package version, I've got to run composer update locally, say 15 times each for 15 projects, then commit all 15, and open pull requests for all 15 etc making the process incredibly slow.
Is there a better way to handle composer update, maybe I need to develop a little CLI application to communicate with the Github api to open PRs and merge them?
What you are describing is exactly what's expected and intended to happen. Full projects with commited lock-files are supposed to install the locked version unless updated.
You could use something like this composer update action to run regularly and create commits when necessary, or work with the GitHub provided Dependabot.
But if this is not coupled with a robust test suite and finely tuned version constraints, you could end up breaking already working projects because some randome dependency introduced an unexpected change in behavior.
I have a GitHub worflow which builds and deploys a snapshot version of a library as a GitHub package, e.g., mycompany.mytool.1.0.0-SNAPSHOT.jar. Whenever I make a new build and deploy, a new asset is created, like, e.g., mycompany.mytool.1.0.0-20210723.145233-1.jar instead which is then somehow associated with the SNAPSHOT tag. This all seems to work and I can access mycompany.mytool.1.0.0-SNAPSHOT.jar without problem.
My question now is, how can I get rid of all these older versions of this jar? Actually I just want to keep the latest version. I can delete them manually via the web-interface but that is a more than awkward task. I would somehow like to automate this too.
This is not possible as of this writing. GitHub staff member Jamie Cansdale wrote this in their community forum:
SNAPSHOT versions are exposed as artifacts inside a regular versions. There isn’t an API for cleaning up artifacts, only whole versions.
(source)
Which means that a single SNAPSHOT version (like 1.0.0-SNAPSHOT) will accumulate all builds you make, and all artifacts will show up on the Assets list to the right of the web page.
The only practical solution I can think of, is that you delete the whole version from a script, before publishing each build's artifacts. Then you'd have the effect of having a single set of artifacts stored as part of the 1.0.0-SNAPSHOT version name.
However this solution is not ideal: public package versions cannot be deleted if they are popular enough (probably to avoid squatting attacks):
If the package is public and the package version has more than 5,000 downloads, you cannot delete the package version. In this scenario, contact GitHub support for further assistance.
Nuget packages are immutable. All documentation makes this very clear.
I am investigating an issue on my internal Nuget server where prerelease packages can be overwritten. Normally, when trying to upload a package with an existing version, the upload will fail. The Nuget server in question is an Artifactory server.
I immediately assume this to be a bug, but in searching to find other people encountering the same issue, I instead turn up posts from people implying this is normal.
This person asks how to always get the latest version when repeatedly publishing v1.0.0-prerelease.
This person found an Artifactory bug where prerelease packages can't be overwritten if they have a dot in the name.
Another Artifactory bug where STABLE packages can be overwritten because they are incorrectly identified as prerelease
I have yet to find any actual documentation saying prerelease packages can be overwritten on Nuget or Artifactory. I would not expect to, but those posts take it as a fact!
Upon more research and testing, the conclusion is this appears to be an undocumented feature of Artifactory.
The closest they come to documenting this is here:
https://www.jfrog.com/confluence/display/RTF/Managing+Permissions#ManagingPermissions-PreventingOverwritingDeployments
You can prevent a user or group from overwriting a deployed release or
unique snapshot by not granting the Delete permission. Non-unique
snapshots can always be overwritten (provided the Deploy permission is
granted).
That section of the documentation is not specific to any kind of repository. It is never specifically clarified anywhere that Nuget prerelease packages are considered "snapshots", but the terms "prerelease" and "unstable" are not used anywhere in the documentation (for any repository type).
Since this cannot be turned off, my team went with using automatically-generated versioning for prerelease packages to avoid having issues caused by package overwrite.
nuget.org does not allow any overwriting of prerelease packages.
How can one depend directly on a package from a github repo? (Assuming the project has no baseline, or there is a reason not use the baseline.)
I've tried the following spec
spec
package: 'Magritte-XMLBinding'
with: [ spec
repository: 'github://magritte-metamodel/XML-Bindings:master/repository' ].
However it failed (Could not resolve: Magritte-XMLBinding [Magritte-XMLBinding.package]), and in Monticello browser under the repo I see only Magritte-Tests-XMLBinding.
What is more, when I look at the unpacked repo (in github-cache/), only the Magritte-Tests-XMLBinding has been unzipped.
The unpacked Tests package is the first in alphabetical order, which makes me feel like Metacello spec just grabs the first package without thinking.
When using git (and github), you cannot depend on packages but in complete projects. You can, however, depend on a project but load just one package of that project.
normally this definition should work:
spec
baseline: 'XMLBindings'
with: [
spec
repository: 'github://magritte-metamodel/XML-Bindings:master/repository';
loads: #('Magritte-XMLBinding') ].
However, while this answer is correct in general, in this case it will not work because the author of the project didn't included any baseline definition that would allow this kind of dependency definition to work, which suggests me he just uses that project as a mirror of the real one... so here you have three possible solutions:
send a pull request to author with a baseline
contact the project author and ask to add a baseline
use the original source instead the github mirror
What is snapshot builds/sources version?
Specific to JDK 7, snapshot releases are for users to download and review while the platform is still being developed.
http://www.oracle.com/technetwork/java/javase/downloads/ea-jsp-142245.html
As a general source control (version control) term, a snapshot version indicates a view of the source code taken at a specific time.
This is not necessarily stable or ready for full use and can be changed in the future, as opposed to a release version which is stable and should be final.
That's another name for so-called daily build (or periodic build or nightly build). A script just builds all the sources periodically. This way anyone who is interested in the recent changes can have the almost freshest version every day. A tag is applied to the sources in the repository so that they can be later retrieved to reproduce the build - that forms "a snapshot" of the sources for that build.
Compare this to "official release" - it is carefully planned. Usually a separate branch is created in the repository where only necessary edits are committed. Then after the team decides it is good enough they run the build process, test it thoroughly and publish.