I have Critical Updates available on my DNN v06.01.03(108).
AS per Security Center I should get upgraded to 7.4.1.
My Question is - do I need to do upgrade directly to 7.4.1 or in steps?
For e.g. 6.1.3 -> 6.2.9 -> 7.4.1
I would upgrade directly from 6.1.3 to 7.3.4.
Always back up your database and the file system before an upgrade, it is recommended that you do the upgrade in a test environment first, but if you don't have access to a test environment you can always restore to 6.1.3 from your backups if necessary.
Chris
Related
We are trying to upgrade Rundeck version from 3.0.27 to the latest version (3.4.7)
We got below questions,
What is the approach to upgrade from 3.0.xxxx to 3.4.7? Could we do a direct upgrade or otherwise, if we have to run through multiple intermediary versions, what are those?
Does upgrading from 3.0.xxx to 3.4.7 fix the log4j vulnerability?
Please help to clarify above.
Thanks
Due to the big gap between 3.0.X and 3.4.X (and the upcoming 4.0.X) the best way to upgrade your instance is to create a fresh 3.4/4.0 instance and then import your projects and keys (exported previously), as a tip, try this on a non-prod environment first.
Rundeck 3.0.x uses log4j 1, so, even if the vulnerability doesn't affect explicitly the log4j 1.x EOL was in 2015 and isn't supported anymore, so, it's important to move to the latest version (Rundeck 3.4.10 at this moment).
we have a cassandra node with 3.9 version.
Is it possible to migrate to last stable version (3.0.11)?
(we dont use any special feature of 3.9.)
Please read downgrade session of this guide:
https://wiki.apache.org/cassandra/CompatibilityGuarantees
The main part:
Downgrading is only guaranteed within minor releases and only to the previous bug-fix release
Theoretically you can try downgrading 3.9 -> 3.7 -> 3.5... etc, but there is no grantees that this will work and will not do problems in the future. Test in some dev environment if you have to do it, or stay with 3.9...
If you've upgraded and EE site locally, and committed all of the changes through i.e. GIT, how are you supposed to upgrade the database on the production environment when you pull the upgraded codebase up to production? I've tried running the installer for the version the codebase is on but none of the migrations run. It says I'm already upgraded when the database is clearly still the older version.
The version number is stored in system/expressionengine/config/config.php.
$config['app_version'] = "273";
In order for the migrations to run you have to change that version to the old version you upgraded from.
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.
When installing a .MSI file using msiexec in silent mode, is it possible to automate it such that on installation failure it rollbacks to the previous version? Assuming that on installation an older application version is already installed.
Yes, restoring the old application version via rollback upon an installation failure is actually a built-in feature of Windows Installer, but you need to configure things correctly to get it to work as you require.
Windows Installer rollback will work as you request if you use: 1) a minor upgrade or 2) a properly sequenced major upgrade that uninstalls the older versions after successfully updating all files. If the major upgrade is set to uninstall the old version before installing the new, the rollback is not available since the uninstall is already over, and the new installer will hence leave nothing installed if it fails and rolls back.
Important: For minor upgrades and for late uninstall of old version in major upgrades to work correctly, all MSI component rules must be followed 100% accurately.
When thinking about a major upgrade that uninstalls the old version after updating, you can view it as a patching operation without having the update packaged as a patch. Windows Installer will actually run a diff on the old and new version and then implement only the required changes, leaving the rest of the application untouched. Depending on the application structure and number of files, this can be significantly faster to install as well.
Late-sequenced major upgrades are also a way to prevent configuration files from being reverted to their original installation status during upgrades. This is a classic issue where config files are changed after installation, uninstalled during a major upgrade and then being reinstalled giving the impression that they are reverted, when they are actually freshly reinstalled.
I have written about Windows Installer Rollback before. Might be worth a read.
No, this is not possible. A major upgrade uninstalls the old version before installing your new one. So when the new install fails, the old version is already removed.
There is a possibility but it involves changing the upgrade sequence which is not always an easy thing to achieve. You should move the RemoveExistingProducts after InstallExecute action
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197(v=vs.85).aspx