We are planning to drop support for all SW versions below 6.4.6.0 in an upcoming major plugin version.
If we configure the supported versions in the Shopware Account correctly, will
the shop owners with unsupported versions be blocked from updating?
the shop owners be able to update to the newest supported version?
Yes, shops with a Shopware version that doesn't match the version requirements of the plugin update will not get a notification about it and won't be able to update through the extension module.
Shop owners will be able to update the aforementioned plugin once they update their shop to a version that matches the version requirements of the plugin update.
In short: You can't have both. Either you deny shops with non-matching Shopware versions the update or you allow them to update to the latest version, but then you can't have the Shopware version restriction.
Related
All previous versions, of the various Microsoft.ApplicationInsights.* packages on nuget.org have all switched to being deprecated. This feels unusual for a minor release, and it's not acknowledged in the release notes. Is there a reason for this?
e.g. https://www.nuget.org/packages/Microsoft.ApplicationInsights.AspNetCore
To answer my own question for anyone else that might be wondering if they need to upgrade Application Insights packages, the short answer is no. You can keep on using the version you are on with the usual consideration for the patch and minor release notes.
This is a recent move by the Application Insights team to comply with the Azure SDK lifecycle and support policy that states:
or has been superseded by a more recent release. In both cases, the current library is deprecated in favor of a newer library.
The main driver, is that support requests are typically resolved by updating to the latest SDK version, so only 'supporting' the latest version ensures we all try that first before teams commit resources to support.
Source: Application Insights GitHub issue.
I have Googled about the lastest Version of ignite ui. The only info I got is, it is "2018.2". Is there any place where I can find info about Patches stuff. e.g. I have now Infragistic.Web.Mvc.dll Version 5.18.1.40. Is it the latest one ?
The core portion of the product, which is on GitHub, follows the same versioning, as the full version. You can check all the available versions, as well as the latest one here:
https://github.com/IgniteUI/ignite-ui/releases
Here you can see our Service Release Schedule and all upcoming and current releases for all IG products.
We have SAP Hybris Commerce version 5.1.1 with custom extensions installed. Now we need to upgrade it to newest version 6.2.
My question is: Can we upgrade it to 6.2 and skip all versions between 5.1 and 6.2? Or must it be done by upgrading to 5.2, then to 5.3 and so on?
Yep - 5.1.1 to 6.2 ought to work (I've been working on a project that's done exactly this).
You will probably have to make some changes - watch out for any customisations you've made - it might be worth reading through the release docs to have an idea of what's changed - off the top of my head the structure of add ons is one area that's a bit different between 5.1 and 6.2, but otherwise things should work OK in theory.
Yes you can directly update to 6.2.
It's important to regulary update your hybris version. You should not have so much gap with current version. Indeed it become tougher to migrate your custom code.
Upgrading each minor version in a row is totally useless most of the time. Only do this if you have issues you can't solve while migrating to the target version.
You should take a look at this migration documentation and this guide (it can be used even if it doesn't match your version).
Note that some stuff like promotion are totally different in hybris 6 so you can expect some trouble to migrate everything. Take care of your extensions generated with old template also.
5.5.1 introduces JDK8 and Spring 4, I would not underestimate this change! Depending on the size of your project I would first go for 5.5.1. Also notice the MySQL change for 6.2 (5.6). Don't forget to declare deployment tables in your items.xml. Search for "third-party compatibility" and "release notes" on the wiki. Also try shifting to the backoffice since the hMC is marked as deprecated.
Yes you can migrate directly 6.2.
The time and difficulty depends on your custom code (and how much it respects good practices : naming conventions, usage of service, architecture respect...etc)
You might also consider that HMC is deprecated in 6.2
Suppose my extension is version 1.0. I write a new feature and release 1.1. Then I quickly realize I've shipped a bug, fix it, and release 1.2.
Now suppose a user with 1.0 is offline until after 1.2 is released.
Will they update to 1.2 or to 1.1?
Do users get updated to the latest version, or to the next version from the one they have?
Users always get the latest version. So you’ll have to integrate any update code for 1.1 in 1.2 as well.
Every few hours, the browser checks whether any installed extensions or apps have an update URL. For each one, it makes a request to that URL looking for an update manifest XML file. If the update manifest mentions a version that is more recent than what's installed, the browser downloads and installs the new version.
— http://developer.chrome.com/extensions/autoupdate.html
We have an application, in which we have series of releases. The current version of the application in production was V2.1
Now we have a set of new UI Screens to be added and related changes to the application. We are planning to release these changes as V3.0.
Do we need to go with Major Upgrade or Minor Upgrade? If we go with Major Upgrade, do we need to reinstall the application? or change the version to 2.2 and go with Minor Upgrade?
Please suggest me some best way to go about with these installers.
Note: We are using Install Shield Premium for building the installer.
If the only changes you are making are to the UI of your installation wizard, there is no fundamental reason to prefer either a minor or a major upgrade over the other. Typically the choice is driven by the changes you are making to the application itself, or the files that comprise it.
A Minor Upgrade will support first-time installations, as well as provide what should be a shorter update for the upgrade experience. A Major Upgrade will uninstall what's currently there before installing the new version. Either can be done with either sets of version numbers - the difference depends primarily on whether you change your ProductCode.
See Patching and Upgrades for details. Some people prefer creating Major Upgrades because they are easier to reason about.