I have installed Spartacus 3.2.2 recently. Can I please know is there documentation available to upgrade 3.2.2 to 3.3 ?
Can I please know if I upgrade to 3.3 will it effect to current development components or pages?
Upgrading to the later minor or patch version of Spartacus should not introduce any breaking changes to your application. It's because Spartacus follows the Semantic Versioning contract.
Sometimes new features introduced in minor versions of Spartacus might require some breaking changes, but in that case such features are not enabled by default. They will appear only when you opt-in to that feature by bumping the feature level in the Spartacus config. You can also opt-in to use the latest SCSS styles, by bumping the styles feature level variable in SCSS.
Significant breaking changes can be introduced only in major version. To smooth the migration process for you, Spartacus team provides the migration docs and automated migration tools (aka. schematics) that will fix some of the the breaking changes in your code and put code comments in your codebase near the usages of the changed Spartacus API.
For example, here are docs for migration from 2.x to the major version 3.0: https://sap.github.io/spartacus-docs/updating-to-version-3/
Related
I'm maintaining a library (MyLib) published on npm that is a vuejs plugin. When I started this library, vuejs was at major version 2.x.x. vuejs now has a new major version 3.x.x that changed how plugins work.
Both 2.x.x and 3.x.x versions of vuejs are supported and will be for a while longer. I want my plugin library (currently version 5.x.x) to be available and supported for both.
Options I've seen or considered so far:
Have 5.x.x as the last version that supports vuejs#2 and 6.x.x and above for vuejs#3.
Easy enough
Doesn't allow me to release a new version with breaking changes that supports vuejs#2 ever if I follow semver rules.
Create a version 6.x.x of my library that supports both versions of vuejs.
Potentially possible, depending on the specifics.
Makes my library bloated because it needs to support both versions of vuejs and have (flaky) runtime version detection to choose the right code path.
Publish a separate library (e.g. MyLib-v2) that supports vuejs#3. Can possibly use a scoped package, but that would force users of 5.x.x of my library to change their dependency name with very poor discoverability.
Not sure how to manage this in a single repo. Monorepo?
Clunky, higher overhead
Is there a better way, or at least a not-awful way of managing publishing my library in this seemingly common scenario?
Use vue-demi. It lets you publish for both vue2 and vue3 in the same project. When using vue2, you have will access to the composition api as well.
https://github.com/vueuse/vue-demi
From the read me:
Vue Demi (half in French) is a developing utility
allows you to write Universal Vue Libraries for Vue 2 & 3
I have a store running Prestashop 1.7.2.4 (with Symfony 2.8.27) with tons of customized files, theme, modules etc.. I just can't upgrade to newer Prestashop versions otherwise i will loose a lot of work in a blink of an eye.
My question is simple, can I apply prestashop version by version from 1.7.2 up to 1.7.8 security patches on my actual installed PS ? That is including Symfony vulnerable issues.
What is your advice.
Prestashop security patches applied over time are listed here , you should search the pull requests related to those advisiories and apply / cherry pick them manually on your release.
This can be a hard task though, especially from such an old version.
Generally, I suggest to move your core changes to modules / overrides so that you can update safely to latest version, so you can also benefit of PHP 7.4 support (note that themes and third party modules will not be overwritten during upgrade).
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.
What is the support for Dojo community support for Dojo 1.8.1 framework?
Our application use Dojo 1.8.1. What is the impact if we are advised to move to the latest framework ?
Dojo 1.x is pretty much "dead" in the sense that only minor maintenance is done.
Migrating to Dojo 2.x or higher from 1.x is not easy, as there is no out of the box migration path.
Of course you can wrap your Dojo 1.x widgets in Dojo 2.x, but then what's the point of using Dojo? Then you can also use another (more widely used) framework.
I don't want to bash on Dojo, as we use it extensively (and successfully) in our company, but the fact that there is no easy migration path to Dojo 2.x makes us want to transition into a more common framework eventually.
More information can be found here: https://github.com/dojo/dojo.io/issues/153
what is the best when it come to choosing what version of rails to use in your development?
I wanted to upgrade to the newest version for the new features, but in many cases chances were high that my existing code would be broken, and a lot of extra time definitely needed to spend fixing it. Should I stick with the current version of rails I'm using? or heading for upgrade?
Any advice or guideline would be really appreciated.
It is useful to always upgrade, because new gems might not support older versions of Rails and you wil get new features from Rails which could reduce code. You can do it step by step, fixing time to time code that will break in newer version of Rails. It more like continuous refactoring.
I think you have to check carefully when and how to upgrade. Here are some hints that may help in the upgrade process:
Patch versions (like upgrade from Rails 3.1.0 to Rails 3.1.1) were normally no problem at all. Upgrade whenever possible, normally you don't have to change anything. Sometimes you have to check if other Gems as well should be upgraded, read the release notes, they give (sometimes) hints about that.
Minor versions (like upgrade from Rails 3.0.9 to Rails 3.1.0) come with new features and non-compatible changes. In the release notes, you will find information what has changed and has to be proven before hand. As an example, look at Ryan Bates railscast "Upgrading to Rails 3.1.0". You normally have to do the following steps:
Upgrade to the last patch version before.
Look at the deprecated log messages. These are the ones that may break after the upgrade.
Tag your current application, or branch to be sure to not destroy anything by the upgrade.
Do the upgrade up to the point you are sure most needed features work again.
Merge back your changes, and continue with the upgrade
(Have done that the last few days for an application I have upgrade from Rails 1.2 to 2.0 up to 2.3.8 to 3.0.0 up to 3.0.9, and now 3.1.1.)
Major version upgrades are even more difficult. You have to ensure that you have enough time and resources to check all the minor glitches you may have. Most of the time, there were resources available by the Rails team that help do the upgrade, like the Rails upgrade helper or the 3 railscast "Upgrading to Rails 3".
In any case, you should at least check if the main Gems you are using (additional to the normal Rails gems) are compatible with the version you want to migrate to. This may be tricky, but sometimes, the information is available.
My experience is, that Major upgrades take time, and if you don't have it, don't do the upgrade. Minor upgrades take some time, and depending on the change (assets in Rails 3.1) come with a price tag, which is sometimes, not all of the times, worth it. Patch upgrades are painless and should be done at will.