I am currently working on a code already made laravel 5.4 and I wonder if it is mandatory to update to the latest version and is it advisable to continue with this version(5.4) there. I really just need only basic stuff on laravel to do my project.
No, it is not required to upgrade the version but it is better if you can keep up, because each version might contain security patches alongside good features and improvements to the existing ones.
Laravel provides very simple upgrade guides that you can follow and if you upgrade them regularly there are almost zero breaking changes.
If you don't like doing it manually then there is a very good service called Laravel Shift which for a couple of bucks can help you with the upgrade.
Related
I have one old CodeIgniter 2 project.
How do I update/upgrade it to CodeIgniter version 4 without any code or function change?
Is it possible?
There is no point in upgrading from 2 to 3 since at the end of the day you won't be able to smoothly upgrade from 3 to 4.
It's a poor time and labour cost calculation advising you to go through two (2 -> 3 -> 4) framework versions if you can efficiently move straight/directly to the latest version. Upgrading a framework alone consumes time, labour and comes with its own set of bugs.
Just come to terms with your current situation that a complete project rewrite directly to CodeIgniter 4 may be necessary. Nonetheless, you may be able to save some parts of your old project.
Upgrading from 3.x to 4.x
CodeIgniter 4 is a rewrite of the framework and is not backwards
compatible. It is more appropriate to think of converting your app,
rather than upgrading it. Once you have done that, upgrading from one
version of CodeIgniter 4 to the next will be straightforward.
There is no 12-step checklist for upgrading. Instead, start with a
copy of CodeIgniter 4 in a new project folder, however you wish to
install and use
it,
and then convert and integrate your app components.
CodeIgniter 3 is in maintenance mode, receiving mostly just security updates.
There is no upgrade path to go from version 3 to 4, especially if you do not want to do any code or function changes, but I disagree that there is no point to upgrading to version 3. Actually, you will be unable to upgrade to even CI 3 without code or function changes. That ruled out, meaning you HAVE to change code or functions, the following might help.
Before you cut your losses and redevelop as suggested, using the below work from Kenji a shot might help. But to do so, you need to upgrade to CI 3 first. Kenji is a very accomplished CI developer with lots of contributions to the framework, including a PHP Unit wrapper for CI. You could follow the guides and upgrade to version 3, and then try to use this: https://github.com/kenjis/ci3-to-4-upgrade-helper/tree/1.x/src/CI3Compatible
The steps to upgrade from version 2 to version 3 may be a big job as well, the biggest one being the initial step - not saying it is going to be easy, but if you try this, and it is not working for you, redeveloping might be your last resort.
For completeness, CI 3.1.13 has been released, and CI is thus now PHP 8.1.3 compatible. The upgrade process from 3.1.11 that I had in my projects to 3.1.13 was literally as easy as 1-2-3.
As a developer I have to make a upfront commitment for 5 years support for a new Laravel project.
My question is - whether I should use Laravel's Long Term Support (LTS) version only?
What could be the potential pitfalls with regards to the support commitment if I use the latest Laravel 5.3 instead of the LTS version?
Any information regarding points to be considered like pros/cons with regards to the support commitment for 5 years when using the latest Laravel version versus using LTS version would help me make a correct decision.
To keep your application framework-agnostic, or to make it easier to swap out or not depend on the framework, the approach which worked the best for me was to isolate my business logic in separate libraries.
I handle those libraries using GITLab server, and I expose them to my composer via satis.
If you use Laravel's routing to map request to a controller, then you can use your library inside that controller and perform the rest of the work.
Constructing your app this way lets you:
isolate business logic
rely on framework to provide correct input since you can use middleware to filter out requests that don't fit.
have it easier when it comes to swapping the framework out
you're using composer, which lets you easily manage library and framework version(s)
This way, you can upgrade your app bit by bit as time goes by, you don't have to rely on having only one framework version forever, without being able to use newer releases.
Good luck with your project!
this is not a code question about laravel 5.*, it's more like to know if you guys develop your applications using packages ("package driven development" ? Not sure if this is the right definition).
What I mean is: Instead of building an application and create controllers in app/Http/Controllers/, you wrap everything in a package and then 'require' that package using composer (like a wordpress plugin).
I'm trying to think in a way to isolate the core Laravel from my specific application and save time later when it's time to upgrade when a new Laravel version is available.
In my case I'm having some issues moving from version 5.2 to 5.3 because I have some customization in the registration and login process - It might be because I'm not using the right approach to write the code (patterns), so I'd like to hear from more experienced Laravel developers.
Thanks!
The great thing about Laravel, there's almost always a package for what you want to do. You can either create your packages as packages on composer, or you can install a module package and create them as modules.
For my projects I tend to use caffeinated/modules. I've tried a few and IMO it's the easiest to use.
We're starting a new project, and we're managing dependencies with Composer. We'll probably build our app on top of Laravel 4. But we'll also create our own library, which we will use for all our next projects, not just this one.
So, we have this terrible doubt: what's the best way to develop a library using composer?
If we list that new library as a dependency, every time we modify it we will have to commit the change to the repository and then call composer update.
That seems terrible!
Is there a better way to do that?
I think there are two ways to handle this, which I use depending on the case:
The library is a pure library, which is standalone, fully tested, and develop it using TDD to ensure that it all works. That way it can be used with the "commit, update" cycle you described just fine I think.
You are developing a plugin or something that must be integrated in something else (application/framework) and testing it standalone is more difficult, or you are developing it very tightly with your application. In this case require the dev-master version of the library so Composer installs it with a git clone (if it was already installed as a tag you will have to rm -rf vendor/your/library to force a reinstall as opposed to an update). You can also force this for tagged releases using the --prefer-source flag. Then once you have a clone in the vendor dir you can very easily work directly in there. If you do work in a team though you will still need to do this commit and then update to make sure the others get the latest version.
The third alternative is to just develop the code in the src/ directory of your application until it is mostly stabilized and then you can extract it as a new package and add it back as a dependency, then fall back on the first two ways I described because it will then be a lot more viable.
If you set the dependency to the repository master branch instead of a packaged distribution file, Composer will check out a working copy into the vendors folder. You can modify this working copy right in the vendors folder, as if it's part of the main project, but then commit it into its own repository. You'll indeed have to make sure to composer update after that to keep the composer.lock file in sync with the development of that library though.
It's still the more convenient way to develop a project in tandem with a dependency.
If you aim to develop a truly awesome library, then you should try to develop it independently of any other software you create.
It should fulfill one exact task only. And this probably is done after some commits, so the initial creation of the library should take only a week or two to come to a stable first version. And this version can be tagged and then used elsewhere.
When tagging, strictly try to follow semantic versioning - that way you can use the library with a version restriction like "~1.0", meaning at least version 1.0, but anything up to 1.9999 is acceptable, as long as it is not 2.0 (which would mean incompatible changes).
And then you really do not need to update any other software when you release a new version of the library. You only need to update if you want to include fixed bugs. Without bugfixes, you can update, but there is no need to do so immediately after the library's new version release.
Composer will take care of all the dependencies you need. The most important thing if you start a new library is to include the composer.json right from the start into the repository.
What if you really want to always include the newest release of the library in every other software you write? I'm not sure you realize the implications this has. It means that you are strictly binding your other software to the most recent library version. Break that version, or introduce a nasty bug, and all your software breaks. So being able to update or not actually is a feature. You will find that all foreign libraries you might use will follow the same release mechanism: They tag a new version if an important bug was fixed, or if a reasonable amount of new features was implemented. They do not wait for you to approve a new version - you have to approve THEIR new version in your software by explicitly updating to the most recent one. And the same should apply to an internal library.
Try to avoid fiddling with "dev-master" solutions mentioned here. They might work, but Composer works best if used with tagged versions. If you have a reasonably stable state of your library, tag it with "0.0.0" and include that version everywhere else instead of "dev-master". And then tag according to semantic version rules.
I would like to know about the compatibility between upcoming versions of KO3. I have heard that once 3.1 comes in, it won't be easy to simply upgrade to it from kohana 3.0 (Wordpress upgrade is pretty swift from 2 to version 3)
If I create my project in KO3 (currently using 3.0.6.2), what are the chances that my project will be easily upgradable to 3.1 or above versions without breaking anything ?
Please answer if you are a real pro on KO3 or part of the development team.. This is important.
Major versions (eg: 3.0 to 3.1) may change the API. Currently, the biggest API change will be splitting the Request class into Request and Response, as well as changes to Request that allow external routing. This also implies that the Remote class will be significantly modified to removed completely in favor of external requests and responses.
You can keep track of the changes scheduled for 3.1 by following the 3.1 roadmap.
I'd just like to point out that wordpress is an entirely different system, it's basically an application written on their own framework whereas kohana is just the framework and you supply the application.
If the wordpress core framework changes then they also change their application to account for those modifications. Sometimes plugins aren't compatible across upgrades so the plugin author has to release an update which makes it compatible. All of this is hidden from the front end users, they don't need to be aware of how it works in order to use it.
Kohana on the other hand has no gui or front end, you're getting nitty gritty with the code. If an interface changes then you'll have to adapt your implementation to suit, there's no way around that.
And as antpaw said, unit tests are always useful for making sure things work as expected! For more info see the unittest repo
it highly depends on the features your have used. give it a try and watch your logs or even better: you run unittests. http://github.com/kohana/core/compare/3.1...master if i picked the right repository. this will help you to see the difference betwenn ko3.1 and ko3.0.7