Is there a best way to publish a previous major version of an npm package without adding a tag for it? Our current major version is 3.x (v3) so we npm publish that version to automatically give it the latest tag. When we publish updates to the 2.x version (v2) we have to give it a tag so that it doesn't automatically grab the latest tag from v3.
We could do something like previous, though the meaning of that is subjective. Really we don't need a tag for v2 at all. Semver works great if people want to install v2. Is there a better solution to not add unnecessary tags than publishing it with a tag and adding a postpublish script that deletes the tag? (That sounds ridiculous as I write it)
Looking at this comment from 2015, "Every publish must be associated with a dist-tag, by design." And I don't see a way to bypass the tag in the current code of libnpmpublish and npm, unfortunately.
Thus, I think you have the best options laid out already: publish under another tag, whether that tag is temporary or not.
However, if I could make a suggestion...
Instead of the subjective previous tag, you could consider publishing the previous versions under a tag called v2. This is a pattern that I've noticed the Angular team uses for LTS releases, for example:
While I think it's of minimal use to a consumer since they could just npm install #angular/core#11 instead of npm install #angular/core#v11-lts, nonetheless it might be a cleaner approach to publish.
Related
I have a private npm package that is currently published to npm. The maintainer before me did not consider automated versioning, and the version is 1.0.58.
I have installed semantic-release and a small GitHub app that can be found here: https://github.com/zeke/semantic-pull-requests
My Github Action is setup properly, because when I push to main, the process goes through and reach the publishing step. However, the tags that are created started at 1.0.0, then 1.0.1, etc.
I tried creating a tag manually on the main branch at the latest merge, that tag is v1.0.58, but when I publish again, the tag that is created is still 1.0.2, etc. As such, I get an error message that says I can't publish "over" the current version.
How do I go the 1.0.59 with a fix:... commit?
Thanks everyone!
Forgot to post solution...
It seems Semantic Pull Requests did not have a proper starting point as the initial tag was created after it was linked to the repository. Uninstalling Semantic Pull Requests, adding the latest tag (corresponding to current version of published npm package) manually and reinstalling Semantic Pull Requests caused to process to go through flawlessly with semantic-release.
I want to upgrade a Bootstrap 4 html/css website from Bootstrap 4.0.0 to the latest version (currently 4.3.1). I have googled this and only see instructions for upgrading from 3.x.x to 4.x.x. Can anyone point me in the right direction?
I agree with the lack of resources provided. However unlike the migration from 3.x.x to 4.x.x, there isn't any loss of component here. But you will see some nasty changes, that will just break things. I would suggest going through the examples for version 4.0.0 and then cross referencing them with the ones for 4.3.1 .This will not solve your problems but it will definitely point you in the right direction.
You found nothing, because there is not much to say (There should be no breaking changes).
So you simple need to update (replace) the library files (CSS, JS, Probably Fonts).
Note: In current days we use Package Managers like NPM and install our frameworks as Packages. In case of NPM, you can find bootstrap here.
Some time after the release of Elm19 I published a library, which I needed for an Elm18 code base: thought2/elm-wikimedia-commons.
This worked well, it's listed in the community driven Elm18 package database: https://dmy.github.io/elm-0.18-packages/, can be installed and all good. Except the fact that the documentation is not shown in the package details, but that I heard is a known bug there. (But still I think this is very bad)
But the main problem is now, how to migrate the library to Elm 19: The actual migration steps are done and live in the master branch of the repo: http://github.com/thought2/elm-wikimedia-commons
The Elm18 versions proceeded to 1.1.0 in the meanwhile and after the migration there had to be done an API change, so I'd assume the latest version to become 2.0.0. If I add this to elm.json, the command elm publish tells me that this would be the first version and I should change this. Which is not right.
After a bit of research, I found out that the package (among other 18 ones that have been published in the same time period) is not listed in this json: https://package.elm-lang.org/all-packages This should contain all packages regardless of versions.
Any ideas what to do? This is really blocking my development, as I'm stuck in both lands now: 18 and 19. Would appreciate a lot if someone has some hints or solutions for me!
You shouldn't need to mess with the version number specified in elm.json.
If you set it back to the version of the package that is already published and run elm bump the elm program will look at the changes you've made to the package's API and set the new version accordingly.
Looking at https://github.com/thought2/elm-wikimedia-commons it doesn't look like any of your upgrade changes were breaking changes to your package API so the version won't be a 2.x.x, it will be a 1.x.x.
You'll need to remove the 2.0.0 git tag as well and instead add a tag for the version that elm bump tells you that your package is.
I consider to use Hexo (the static blog generator) based on npm. I wonder one thing, what if although one npm package (dependency) will not be longer available? Each package has its own author and it can cancel support or completely remove it from npm's repository at any time.
So what do I do if missing one of the npm package affect on running Hexo and consequently I'll not be able to generate my blog in the future?
Although this can happen (and happened at least once), it is not a serious problem ussually. While you will be waiting until somebody will fix the missing dependency (it take place quickly on popular packages like Hexo) you can use older working version. And if you want to be 100% sure, you can commit node_modules together with your web sources (see discussion here).
My standard route has been to go to confluence, find the docs sections, then navigate through to the install docs for the version, e.g. sakai 10:
https://confluence.sakaiproject.org/x/iYGLBQ
Through one means or another I happened across the source route to this too, so starting here....
http://source.sakaiproject.org/release/
You get redirected to the latest stuff, and appended version numbers to that url gives you other docs, e.g. adding 2.8.2 or 10 to the end of the url
But the links to what I should download are quite often not there, at the time of writing the 10 tar ball and zip in the confluence links are dead and the source.sakaiproject links doesn't have the 10 docs yet (redirects to 2.9.3) presumably this is because v10 is not released yet....
So, I'd like to evaluate a new version of a sakai source install, what's the best way to do this? (considering the official documentation for install is still being formed)
Do I download the latest SVN, or the latest RC or the latest beta or??? How do I know what's best to test against without being "too" bleeding edge? Is there a recommended tar ball/zip link to test against? Is there a "latest good" SVN branch?
The latest code is always in the Sakai trunk (currently svn):
https://source.sakaiproject.org/svn/sakai/trunk/
That code may very well not be stable though as it is where things are being actively developed. If you are not actively developing then you should stick to the releases as indicated on the project website here:
http://sakaiproject.org/current-release
If you want to use something in between (say an upcoming release) then you can grab the most recent tag or maybe use a recent branch (both currently in svn, latest shown below at the time I write this):
https://source.sakaiproject.org/svn/sakai/branches/sakai-10.x/
https://source.sakaiproject.org/svn/sakai/tags/sakai-10-rc02/
The reality of the situation is that if you want to use something other than the release then you should really participate in the dev community for Sakai. Joining the mailing lists and the weekly calls will provide the information you are asking about and much more.