I have an question regarding updates to the framework of a Laravel application.
Normally I run the composer update command to update all of its dependencies. For the laravel framework the package laravel/framework is used.
But they made some changes in this package which require you to make changes in the core application (not in composer). The core application is the package laravel/laravel.
For example, in this commit they have made a function called confirmPassword() which refers to a file ConfirmPasswordController.php in the package laravel/laravel.
But this file didn't exists on my application because my application is not up-to-date.
My question
How do i keep my core application up to date?
Errors
See a typical example of updating the dependencies but not the application here.
First of all... This is not an easy question and IMO there are MANY possible scenarios... Depending on the code you developed, the packages you're using, the version you want to use, and so on...
Anyway This is what I would do in this situation:
Let's say for example I want to upgrade from version X to version Z where Z is two major / minor releases ahead of X
Step 1
Follow the next steps for one major / minor realease at time. Once I've tried to upgrade an application from Laravel 5.4 to 5.6 and it was completely broken. So I decided to upgrade to 5.5 and test the everything was working and, in case, block at that release. Luckily when I've upgraded from 5.5 to 5.6 (after code fix) I've managed to make everything work as it should.
Step 2
Upgrade the core framework and the plugins, check for errors during the upgrade and ofc, check the official documentation for any kind of compatibility problem
Step 3
Laravel has it's own upgrade guide that should be followed step by step. A good chunk of errors can be solved simply following that guide. There may be some plugins that doesn't provide it but usually the problems are releated to new features... It's hard that a method, class or trait has completely changed from one version to another.
Step 4
This step can be omitted, but from the example you've provided maybe it's better to add it. When there is a new feature that requires a specific class or trait or whatsoever, the simplest way to check if the error is thrown because of a file missing (and that is part of the "boilerplate") or has a different nature, is to create an empty project with that specific version and make a comparison with the "default" files.
For example, if you made no changes to the LoginController, checking if the new version has any kind of updates, may be the solution.
You can do this manually, following the upgrade guide for the version you're upgrading from/to, for example this one.
Alternatively, Laravel Shift is a paid but fairly inexpensive tool that will do it for you automatically. Since it's making changes to your project, you should carefully review everything it's done.
Related
I made a Laravel app as a side project and the final version was 2.6.4
I choosed to rewrite it completely and rename.
I changed blade templating to Vue.js, made a better Model and Controller structure, etc.
Should the new version be 1.0 or 3.0
You should make it 3.0
As it is the same project you've been working on and made improvements in.
As maybe your question or confusion is arising from the fact that you've made a complete re-write. But with projects, it usually happens. A complete re-write is usually marked with a version bump.
If the project, however, changes and caters something else than you begin with.
That project would be named differently and have 1.0 as the version.
im currently working on an update from laravel 4.1.24 to 5.6 The problem is i got nearly no experience with laravel. My question is now, how do i properly upgrade. Should i first upgrade to 4.2 and then to 5.0 and so on or would it be better to upgrade directly to 5.6 and how should i do this? I mean there are so many changes that i think i could miss something.
Also the project is just in a github repository, so it's hard to check if it's still working after an upgrade because i dont got the old modules. Or would it be enough to go on laravelshift. com and just upload it there to go from 4.1 to 4.2, 4.2 to 5.0 and so on.
Best regards!
The Laravel documentation contains a whole list of breaking changes that can help you to upgrade your application to a newer version. Laravel Shift is a service that checks and updates these changes in your project.
However, there is no way of being sure that your project will still work after these upgrades. Especially if you are using external modules its very risky.
If it is not required, I would not recommend upgrading from 4.1.x to 5.6 unless you have a lot of time on your hands. A solution could be to set up a completely new 5.6 project and add the project code file by file and test the implementations.
Start from here and follow instructions to upgrade it to 4.2. Then go through your packages and update their versions accordingly. When done use dropdown list in the top-right corner to select next version (5.0) and repeat it until you are at 5.6.
You definitely need to be able to run your code and test it somehow after each step because there will be problems. From 4.1 to 5.6 is a big leap and a lot of packages might have breaking changes etc. I only migrated as far as from 5.1 to 5.6 and it took me whole day to fix everything.
As for automated upgrade you can try it as well, but as I already mentioned you need to be able to test your work because all packages need to be updated as well.
I want to upgrade laravel version from 3.1 to 5.x. What steps I need to follow to do this?
Approach I found based on research is
Moving 3 to 4 first and then from 4 to 5.
Fresh installation of laravel 5 and change my code accordingly.
There is no easy way to upgrade Laravel 3 to any other Laravels. There are quite a bit bottle-necks there
1. Laravel 3 is based on Symphony2 and mostly influenced from Sphinx, on the other hand laravel4-5 is based on Symphony3.
2. Core Laravel3 is build on base level, so everything you build in your application folder builds up on top of Laravel instance, but Laravel4 and 5 are a composer package. So basically you are using these packages along with others to build your system.
3. Laravel3 has bundles and Laravel 4-5 has packages. Bundles has been deprecated quite long time ago and most of them are not being maintained anymore. Building process and structure is totally different than packages work.
and this list goes on and on.
Like I mentioned at the beginning there is easy way for it. By easy I meant running a script and everything is brand new.
From views to application, to schemas and Eloquent, many coding style and structure is changed in Laravel4. So long story short, there is no upgrade documentation for 3 to others because the only way to upgrade is rebuilding the application with new way. Even if you find a script to automate most of your code conversions, you still need to go through bundles and find right packages, add them to your composer and find old usages of them in your code to replace with new way.
The laravel docs give pretty good guides on how to upgrade (you first have to upgrade to 4, then to 5).
But since Laravel 5 is so different in every way, I wouldn't be surprised it's actually faster just to rewrite everything. At the very least it's safer and more optimized!
I am working on a CakePHP 3.0 project which I want to update to 3.1-RC1. When I try do so I get an error:
Problem 1
- akkaweb/cakephp-facebook dev-master requires cakephp/cakephp 3.0.x-dev -> satisfiable by cakephp/cakephp[3.0.x-dev].
Now this plugin in question hasn't been updated in 6 months and I suspect it might work OK in CakePHP 3.1, so I would like to try it out.
How do I tell Composer to ignore this particular version incompatibility and proceed to update my CakePHP package?
I am aware of version aliases, but I only want the exception to be for the plugin in question, and not for everything else.
You should be frightened when you want to use a software that isn't maintained, hasn't released any tagged versions, and depends on developer branch versions of other important software. I wouldn't use this package at all. It will harm you in the long term, even if you made Composer install it.
If the current author does not respond to your contact attempts, you should be able to fork the project (in compliance with the license it gave you) and start maintaining the package by fixing the problems you have. Because that's what you'd have to do anyways when using unmaintained software. It will allow you to use this package in a much cleaner way, instead of coming up with a dirty Composer hack to make it install.
We have a software that has couple of executables inside. One of the executables is Windows service, and it doesn't change that often, usually we release many updates to the main executable, but the service version is same inside installer.
When service is installed first time or upgraded with newer version, we need to run custom action. We managed to solve first install part, but we don't know how to determine that version we're installing now is newer than one that already exists. Sort of if(newver > oldver) run custom action.
Thank you in advance
- Jack
You can try using the upgrade rules of your package. More details here: How to implement WiX installer upgrade?
Rob Mensching (the second answer in the linked thread) shows an example for upgrade rules. You should first familiarize yourself with the Upgrade table and how upgrade rules work. There isn't an easy answer or a quick fix for this in WiX.
Basically, you should have 2 upgrade rules
the first sets a property when an older version is found
the second sets another property when a newer version is found
After that you can use the older versions property to condition your custom action. For example, if the property is named OLDERVERSIONFOUND the custom action condition can be:
OLDERVERSIONFOUND
or something like
OLDERVERSIONFOUND > "1.0.0"
Your best bet is to store the "service" version somewhere in the registry, search for that registry value during upgrade and run your CA if newver > oldver (and the CA should also update said registry value to newver)
Note that Custom Actions are (generally) an admission of failure. I always try to separate out the configuration portion of setup to a pre-install (for sysadmins doing deployment) or post-install (for interactive installations) step - often a separate executable.
Declarative installations with no custom actions are much more reliable - if you can figure out how to rewrite the service so that your custom action is no longer required, you'll be much better off in the long term (this doesn't help when you're under pressure to release now, but it's something to think of for future releases)