I have a npm package which is currently lets say version 1.2.2. I am just about to release version 2. I still want to be able to maintain version 1 alongside version 2 for bug fixes and so on. What would be the best approach to separate code of both versions. #latest will be stored on git master. Where would you store version 1 code? Separate branch, repo? How do people do it in the industry?
Where would you store version 1 code? Separate branch, repo?
Yes, you should maintain two or more branches.
Master branch could be currently working code so it can be either 2.0.0 version or 1.2.2, but since you haven't released version 2, master branch should contain 1.2.2.
And you can create 2.0.0-dev branch and work on it.
After you release version 2, you can merge 2.0.0-dev branch to master branch, and maintain 1.2.2 branch for LTS support and bug fixes.
Also, you can manage releases in github, if you're using it.
Related
In the given scenario, new Dev A has a new version of npm (8.3). He does a clone of the repo and npm says the package.lock file needs to be upgraded from lockFile version format 1 to version 2. Then he checks that in. So now the repo has a lock file with format version 2 and other devs pull that down.
Time goes by with no problems. Then Dev B, who's on version 6.13, installs a package. Is it normal that the lock file will change back to version one FROM version 2? In other words, each time a dev with a different version of npm that employs a different format, upgrades or installs a package, is it normal that it changes the lockfileVersion format over and over depending on their npm version and its format? Or should it stay with lockFileVersion 2?
Trying to identify what happened recently with our packages, and I'm looking to exclude this as a possible issue.
From what I read fileLockVersion 2 is supposed to be backwards compatible. But is it supposed to change back and forth like that? I wouldn't think so because how can someone with version 2 (Dev A) use version 1 if it was required to upgrade to version 2 in the first place?
So am I correct that once it's on version 2 it should stay that way? And if so, what would cause it to go back to version 1.
Thanks
No, it's not normal for developers to keep flipping versions like that, but it's fairly common for it to occur. We also had this happen specifically with package-lock.json so we told everyone to upgrade, and we made sure to upgrade all of our build agents. Similarly, in Visual Studio solutions some developers occasionally changed the version of VS back and forth from 2017 to 2019 a few times before we told everyone to just upgrade to 2019.
Generally it's best to avoid it if possible.
what is the best practice to upgrade the dependency v-calendar from beta to the latest version v2.3.0?
I know the question is opinion based, but I am new to the field, what are the pros and cons of the way to do the upgrade.
We use "v-calendar": "~1.0.0-beta.14" in production. The latest version is currently v.2.3.0
I can think of two ways:
update to the latest version with yarn add v-calendar#latest?
upgrade incrementally until the latest version is reached with yarn upgrade "v-calendar"?
What should I do to reach the latest version? thank you
ps. we are using vue: ~2.6.10
Unless the package you are using has an upgrade guide (99.99% of them don't), there is absolutely no point in doing an incremental upgrade. If it has an upgrade guide, read and follow its instructions.
The easiest way to upgrade is to change the package version to latest (in most IDE's if you press Ctrl/Cmd and hover the package number shown in package.json a tooltip will show you currently installed version, latest wanted version and latest available version). After you changed it (by typing the latest version in), run yarn install.
In the vast majority of cases, that's all you need to do, because most packages are built with backwards compatibility (existing features remain and new features are being added). If that's not true in your case, you'll have to reimplement it following their documentation. Typically it's no big deal.
Also, note there is no risk in attempting to change to a newer version. If things break, you just go back to package.json, change version back to lower, run yarn install again and everything is back to square one.
How does different mikro-orm packages versions correspond to each other? Could I possibly use #mikro-orm/core 4.0.0 and #mikro-orm/nestjs 3.1.0 or other variations of different #mikro-orm packages and their versions? Should all #mikro-orm packages be installed with same version?
It's 3 questions but I feel they are pretty much the same since they try to clarify concept of version matching in mikro-orm for me.
All packages that come from the main repository are released together, you should always align their versions.
https://github.com/mikro-orm/mikro-orm/tree/master/packages
The rest is not dependent on exact version, but in general, use the most up to date one. There are currently 3 packages that live outside of the main repo, the nest adapter you mentioned and 2 highlighters.
Btw there is no such release as #mikro-orm/nestjs 3.1.0, first release was 4.0.0 and current is 4.2.0.
edit: apparently lerna is aligning only minor/feature releases, so it can happen that some packages are not on the very latest patch version, example of that are mongo and reflection packages, that are still on 4.1.0, while the rest is on 4.1.1. but again, use the latest everywhere and you will be fine. Your IDE should guide you in knowing the latest versions.
I'm having some problem with my installed pods. They are not pulling the most recent (bug-fixed) version of their libraries from Github, and hence my Xcode compiler is full of warnings. I don't understand how Cocoapods works an entirely, and I'm wondering if anyone can clear it up.
How does Cocoapods know when a new version of a library is available?
What is required for Cocoapods to retreive the latest version via the
sudo pod install
comand?
How often and for what reason does a podspec need to be updated? Does it need to be updated by the author of the podspec only or by anyone?
Cocoapods are usually linked to a specific repository tag and version, so looking at AQGridView we can see two versions, version 1.2 refers specifically to the commit commit => 'f6c5589a6dabfff693fc7def7342327b9b0df3f9 whilst 1.3 differs. If the first time you ran a pod install 1.2 was the last version you would always get version 1.2 so as to not break backwards compatibility.
If you wanted to update to version you could run pod update which would check your existing podspec file and look for the latest versions ( on cocoapods! ) and use those.
If you wanted to use cocoapods but access the latest version specifically for one there is a wiki page saying how to do it here
So with that down,
When someone updates the Specs repo the pods on your computer doesn't know this instantly, you can run pod repo update to ensure you're at the latest. I expect it auto checks every so often.
Mentioned above, if you run pod update it will use the latest podspec versions
Podspecs are updated as often as people want their libraries to have a version number, ideally whenever you release a point release you should also submit a corrosponding podspec to the repo and then everyone knows they can update. It is quite often updated by volunteers, but we do get authors updating their own libraries.
pod install does not install the newest versions! Using the newest version by default is a bad idea. You should always specify the exact versions or use the pessimistic version constraint (~>).
To get notified about new versions you can use VersionEye. You can directly follow pods to receive email notifications as soon updates are available. In additional to that it can directly monitor your GitHub repository and notify you about out-dated pods in your project. That is the most convenient way. You can read more here.
if you get the notification for a new version you should first check the version number. If the pod project is using http://semver.org/ you can already on the version number see if you can update without breaking your build. In the worst case it's a major release, which very likely will break your build. In that case you have to check the change logs and the migration path. If you wanna learn about how to update right, check out the slides to continuous updating.
If you want update CocoaPods (newest) version, you can do $sudo gem install cocoapods
if you want update all library of your project, you can direct do $pod update ,or update someone library you can do $pod update [POD_NAMES ...] <<--- those command you can use anytime to update your project(if new library have been released), unless check each library by manual.
Tools such as liquibase and flyway certainly make it easy to upgrade your database. What I haven't gotten straight in my mind is how to best handle changes that occur both on a release branch and trunk.
An example:
My code that is in product is version 2.5 and lives on a release branch. In the meantime, developers have started working on version 3.0 which lives on trunk.
A bug is found in production. A database change script is made (2.5.1) and committed to the release branch. The same change script must be merged back to trunk (3.0.1?).
Version 3.x is released into the wild production db's will already have the change from 2.5.1. The upgrade could potentially fail.
Conversely, if I'm creating a db from scratch if i was using a forward only strategy I would have the same change occurring twice (2.5.1 and 3.0.1).
How are others handling this scenario?
You are right to recognize that production DB changes will always be linear.
To solve this you should place DB migration 2.5.1 both on the branch and on trunk. And not create a 3.0.1 with the same changes!
This way it will be deployed with the branch, but also with trunk.
Upgrading production to trunk will then
find migration 2.5.1 and skip it, as it has already been applied
find migration 3.0 and apply it on the 2.5.1 db
There is, of course, an ever better solution. And that is to get rid of branches altogether and always release from trunk using to feature toggles instead.