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.
Related
I recently had to upgrade my Gitlab server. I found out that gitlab-7.8.1_omnibus is too old and there is no direct way to update the current version to the latest version gitlab-ee-12.7.6-ee.
The best way I've found is to install a new server with the latest version of Gitlab and ask the users to transfer their data to the new server.
Is there a way I can transfer the data for the users?
I would like to prevent this from happening again. How do I make sure my Gitlab server is updated evey time a new version is available.
Do I must to run 'yum update' before I run the Gitlab update?
I.
GitLab 7.8.1 is indeed a very old version.
You can avoid upgrade path and just move Git repos, if your number of projects and their customisations and integrations is low.
Every clone of git repository is supposed to have all (or nearly all) history.
So you can just:
create a matching project on the new GitLab server
add a new remote to your git clones on your machine git remote add origin ...
push to the new remote
II.
You can still try to upgrade your current server in several hops, see upgrade recommendations:
We recommend that you first upgrade to the latest available minor version within your major version
Old versions I could find are:
8.0.0 as the oldest Docker image
7.10.0 as the oldest deb\rpm package
7.14.3 as the latest in 7.* release as deb\rpm package
First make sure you minimize any customisations you have in /etc/gitlab/gitlab.rb as those parameters change a lot across versions, and require manual reconfiguration.
Then you can try:
upgrade to 7.14.3
then to 8.0.0
then to the last in 8.*
then to 9.0.0
etc
III.
Once you have a stable recent version of GitLab server:
GitLab publishes new Major release yearly, and every Major.Minor release monthly (22nd day of the month), see maintenance policy, I really recommend upgrading every month
wait for a couple of weeks though, as they often release patches for bugs quickly found by other people
review release notes
read upgrade documentation
don't forget to backup
upgrade
I am trying to upgrade to the latest build of Acumatica 2018 R1 from the latest version/build of 2017 (with a clean Sales Demo database) and get the following error:
The database cannot be upgraded because your current build (17.208.0034) is incompatible with the build (18.101.0039) you want to install. Wait for the next update package that will be compatible with your current build.
Does anyone know which 2017 R2 builds are compatible with 2018 or is there some type of workaround or do we have to wait for another version of 2018? Thanks
I would assume update 1 for 2018R1 would work with update 7 because update 8 was just released and the code should be comparable. If you don't have a backup of update 7 for 2017R2 and ONLY if this is demo data I have in the past just reset my version number in the Versions table back to a previous version. Try to set yours back to 17.207.0029 (requires access to SQL and an update statement to the Version table)
The problem here is you don't know what kind of issues you are going to run into as you are trying an unsupported version by changing the existing version value. Make sure you test plenty before you demo if going this approach :)
Best result is to restore to a 17.207 database backup and then upgrade. I backup each version before upgrading for issues like this (local development databases).
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...
My existing project, uses Azure .NET SDK 2.1. I wanted to upgrade the SDK to 2.4, so i dowloaded the latest from here for VS 2012. After successfull installation, when i opened up my solution, the cloud projects did not load. Thats ok, as they have been created using a lower version. So i removed them and created newer cloud projects.
But the thing which astonishes me is, there are many places in the worker role project where its throwing build error as it is not able to find out the assemblies and methods. Is there any easier way to upgrade to sdk 2.4 without making code changes. Which i think is a bad idea to make changes to the stable code, just for SDK upgrade.
When you open a project created using 2.1 SDK and try to open it using 2.4 SDK, you should see the project upgrade dialog which gives you the option to either download 2.1 SDK or convert existing project to target 2.4. Selecting the convert option should upgrade the project to 2.4. Any errors in this process will be reported in the project migration summary report.
If you are not seeing this dialog, then you might still have 2.1 sdk on your machine in addition to 2.4 sdk. In that case, you can go the Azure project properties. That will give you the option to upgrade your project to 2.4.
In regard to the build errors that you are getting for new projects, the error details will help in identifying the root cause.
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