I am working on a project and the client is using freePBX version 2.0.X and they want to upgrade their version to 14.0.X. How should I do this keeping in mind that all the data and configurations needs to be migrated to the newer version?
edit: to those who are marking it negative, I am new to this and if I new the answer then, I wouldn't ask.
You have update 2.0->2.2. After that 2.2 -> 2.4, 2.4->2.5, 2.5->2.6
After that you have updat 2.6 to 13, 13 to 14.
Some of this upgrades not go without problem, huge experience required.
On upgrade from 2.6 to 13 you have also upgrade asterisk to version 13.
If you have no very complex config, in most cases faster will be backup extensions, dids, restore, put all other config items.
ps also you need have archive for thoose version,i think it will be complex to find something below 2.4
Related
This question already has answers here:
how do I install a previous version of meteor JS?
(5 answers)
Closed 4 years ago.
I recently updated my Meteor version from 1.6 to 1.7, which seems to have unexpected bugs. In an attempt to fix them I reinstalled Meteor, which probably deleted old installations, which means I can't go back to 1.6. If I change the version in the .meteor/release file from 1.7 to 1.6.1.2, it says that I need to update the release to 1.7, which means I can't use the old version anymore. Is there any way I can install 1.6 version?
I'm using Windows 10 PC.
Are you tracking your project in version control?
The usual advice here is that you should make sure your app is committed to some VCS before starting the update so you can roll back. This works because Meteor uses the versions in .meteor/release and .meteor/versions to keep track of what to use to run your app.
Rolling back
In the unlikely event that the update leaves your application in a bad state, and you don’t feel like debugging it right away, please make sure your application’s .meteor directory is committed to your version control system (e.g. Git, Mercurial, etc.) before the update, so that it’s easy to revert the changes if you encounter problems.
If you don't have any version control, then my recommendation would be to update .meteor/release as you have tried, and also delete .meteor/versions and allow Meteor to pick versions again that are compatible with 1.6.1.2
Alternatively you could try creating a new project with Meteor 1.6.1.2, add the same package dependencies and copy over the release and versions files for the same set of packages.
$ meteor create 1612 --release=1.6.1.2
$ meteor add <packages from your app>
After you've copied them over, meteor should use version 1.6.1.2 and compatible dependency versions
We are thinking of upgrading our Symfony app to Symfony 4.
The app is currently on Symfony 2.6 version (we can upgrade to php 7).
What are the benefits to upgrade through 2 stages from 2.6 to 3 then from 3 to 4 compared with upgrading directly from Symfony 2.6 to Symfony 4?
There are some differences between SF 3.4 and SF 4. So if you have an older Version you should first upgrade to SF 3.4. This is because SF 4 has another structure and use the flex framework. It's possible that you have to change a lot of things during the migration. If you have the time you can do that. If your have Unit-Tests it's much easier to find all the problems.
In general you should read the migration documents that describes the changes in every version and change your code in that way.
https://symfony.com/doc/2.7/setup/upgrade_major.html
So better you upgrade first to version 3.4. Then you have the compatibility to your older code and plugins but no new features that come up in SF 4. But all that depends on the size of your application.
You can upgrade, but it will be very painful because the development methodology has changed very much between symfony2 and symfony4. Will better to install separate Symfony 4 project and implement each component of application separate.
You should upgrade by this step:
1 -Symfony2.6 to Symfony2.7
2- Symfony2.7 to Symfony2.8
3 - Symfony2.8 to Symfony3.4
4- Symfony3.4 to Symfony4
I am wondering why support for Symfony 3.2 will end on July 2017 while Symfony 2.8 will on November 2018?
I will start a new project and I am little lost about what version of symfony to download. The last version or an old version that has more support.
Symfony 2.8 has long term support (LTS). This means it will be supported up to four years after its release. Since the release was November 2015 the support will continue until 2019. 2.8 will be the last version of Symfony 2, wich means that Symfony 2 will be end of life in November 2018.
Symfony 3.2 is a "normal" version without LTS. The next LTS version of Symfony 3 will be 3.4 which is scheduled to be released in 9/2017, which means that Symfony 3 will be end of life in 2021.
You can find the complete release schedule including Symfony 4 at this link. Symfony Release Schedule
TL;DR: Use Symfony 3.x, it will be supported 3 more years than Symfony 2.
EDIT: The symfony website mentions different values for the number of years a lts version is supported. The page I linked mentions four years, so I corrected the numbers above. The three years I mentioned in the original post can be found here. version 2.8 roadmap
Take a look at this release schedule. Version 2.8 is part of the Long Term Support. You could go with version 2.8, but it makes more sense to use the latest version of 3.2, and then use composer update to update your project. Version 3.4 should be coming out soon.
You have a choice not to update your Symfony version if you don't want to. I'm not sure if that addresses your question?
I would choose Symfony 3.2, it will be easier to upgrade to the 3.4 release which is a long time support version (2021).
Check here
So I updated to swift 3.0 and now my projects with realm 1.0.2 all give me an error.
RealmSwift compiled with older version of Swift language (2.0) than previous files (3.0)
I also tried to build a net new project and still get the build error, so I know it is not a conversion issue on the Swift side.
I found several Swift 3.0 beta users and tried to run the script to update my version to 3.0 and several other options. The last few posts appeared to use Cocoa Pods - which I don't currently use. Is that the supported fix path?
Any help or direction would be greatly appreciated.
I haven't tried it yet, but here is what should work.
Essentially, the compiler gives you a description of what went wrong. The framework was compiled with Swift 2.0, while your project or other files were compiled with Swift version 3.0 (which means you made the switch after upgrading to the new version of Xcode.
To fix this, you need to use the Realm framework compiled with a Swift 3.0 compiler. Since the Realm team doesn't yet provide a precompiled version compiled with Swift 3.0, you have to do so yourself. To do that, go to their Github repository, and follow the instructions in the README under "Building Realm":
Prerequisites:
Building Realm requires Xcode 7.3.
Building Realm documentation requires jazzy
Once you have all the necessary prerequisites, building
Realm.framework just takes a single command: sh build.sh build.
You'll need an internet connection the first time you build Realm to
download the core binary.
This should generate the Realm framework with the current compiler version, which you then just have to use to replace your current Realm framework with. After that, everything should compile as it used to.
As stated before, I don't know if this actually works, as I haven't tried it yet. I don't exactly know if Swift 3.0 is supported by Realm yet or if there are any other issues you could run into. So please let me know how this works out!
In my case I'm upgrading the memcache module,though there's a README.txt but it seems not operable :
1. Install the memcached binaries on your server. See http://www.lullabot.com/articles/how_install_memcache_debian_etch
2. Install the PECL memcache extension for PHP. This must be version 2.2.1 or higher or you will experience errors.
3. Put your site into offline mode.
4. Download and install the memcache module.
5. If you have previously been running the memcache module, run update.php.
6. Apply the DRUPAL-5-x-cache-serialize.patch from the patches folder that
comes with the module. Version specific, so use DRUPAL-5-6-cache-serialize.patch
if you are running Drupal 5.6.
7. Start at least one instance of memcached on your server.
8. Edit settings.php to configure the servers, clusters and bins that memcache
is supposed to use.
9. Edit settings.php to include either memcache.inc or memcache.db.inc. For
example, $conf['cache_inc'] ='sites/all/modules/memcache/memcache.db.inc';
10. Bring your site back online.
Especially step4, does it mean just unpack the module and replace all stuff in original directory?
My current memcache version is 5.x-1.9 and there's 5.x-1.10 available,but I don't see it available at admin/logs/updates
Step 4 means that you remove the old module directory completely and only then unzip the new module code. You don't want any remnants of the old code.
Also note, that
Not all module developers think the same about dot releases: sometimes 1.2 and 1.3 are major rewrites or come with completely new features, themeable-functions, pages or APIs.
Not all upgrades are compatible with others. Sometimes you cannot update module B to 1.4, because of its dependency with A, A seems not compatible with 1.4 (yet). Drupal does not support dependencies on versions.
Major releases imply (but do not guarantee) incompatibility, or even complete rewrites: Upgrading from 5.x-1.4 to 5.x-2.1 might force major rewrites of custom code, including your theme.
Security updates often are dependent on earlier releases: 6.x-1.2 might introduce new features (that you do not want, or wish to ignore), 6.x-1.3, can be a security-release that requires (some of the) the changes in 6.x-1.2 to be available. You must then either fiddle around with patches, or go trough that feature release anyway.