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.
Related
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.
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'm not a developer myself, but my company develops and supports a large web application for insurance brokers.
Since way back we've been using ExtJS 3.x and as we went further the harder it got to migrate from 3.x to 4 and now to ExtJS 5. Due to the structure of the application and demands from out customers we cannot afford to freeze development and focus on refactoring our interfaces.
But we still want to use the benefits and functionality of the ExtJS 5.
My question is - is it possible to use both versions of the framework in the same application? For example, developing new grids and modules with ExtJS 5 and gradually migrating existing forms.
Did anybody have this sort of experience? Or is it plain nonsense and will never work?
Thanks to everyone in advance.
I find this question very interesting. I had a similar challenge, when I had to migrate our in house app from legacy Jxlib to ExtJs4. Putting my experience together with #Lolo's answer here is what I can advice:
Build on a new solid foundation. You could be tempted to keep your app in ExtJs 3.0 and start grafting new ExtJs 5.0 components on it. If you really want to take advantage of all the new features of ExtJs 5.0, you should start off with a clean, simple MVC app in ExtJs 5.0, that could be as little as the main window and the main menu. You could then bind all existing menu entries to the existing ExtJs 3.0 code. This will allow you to start with a really clean thing, keeping all the old functionality, without rewriting the code, and allow you to develop all new features with clean ExtJs 5.0 code that follows current best practice recommendations.
You will face two stumbling blocks:
You have to separate the namespaces in Javascript and CSS. Here also, I would advice to change the prefixes for ExtJs 3.0, and not for Ext 5.0 (I ignore if ExtJs 5.0 includes a sandbox file). The reason behind is that all your new ExtJs 5.0 code will be standard compatible, while only the old legacy code becomes incompatible (what it is anyway already). This will represent some code refactoring though, because you would need to replace all Ext. occurrencies in all your code with Ext3. or similar (the same applies to CSS, but will be much less work). I hope for you, that ExtJs 3.0 has a sandbox version, because I think refactoring their code would be a lot of work (but not impossible).
A major feature of ExtJs 5.0 (as already for version 4.x) is the automatic building and compiling of an MVC application using Sencha Cmd. This didn't exist yet for ExtJs 3.0. I think it is crucial that you start straight away using this tool. I will allow you to really take advantage of all the enhancements (declarative programming instead of imperative, advanced MVC and MVVM features). It will radically change your coding style.
To get this work, you compile in a first step you old code in one Javascript file. Sencha Cmd must not recognize this as an Ext app. Then you simply add requires: 'Oldapp' in Application.js and ExtJs will include a file called Oldapp.js. That file should define a class Oldapp and include all the rest of your application code:
Ext.define('Oldapp', {
// Just what ever you need
})
// All the rest of the code of you old app
Then layout all the folders and files of your new code according to the MVC or MVVM specification (whatever you prefer) in the Ext doc, and Sencha Cmd will build you the whole app correctly.
I think this all allows you to take advantage of all the new features immediately, building on a clean, standard foundation with only minor code refactoring. It sounds like eat the cake and have it too, but it is possible.
But this will take a huge mental step: You must learn ExtJs 5.0 like something new and try to forget all you know already about ExtJs. You won't use Ext.ready anymore, Ext.Loader will handle this under the hood. Nor will you instantiate Ext objects from declarations (ban panel = Ext.create({xtype: 'panel', ... stuff), stick to Ext.define('Myapp.view.Mypanel' .... There are many other points where everything changed since Ext 3.0 ...
This last point is in my opinion the biggest stumbling block, much more important than the two technical points explained before: It is difficult, but crucial to reeducate yourself.
You can use sandbox version of Ext Js 5.0 and "normal" 3.0 (I don't remember if 3.0 is also available as sandbox).
Then you can change prefix for all 5.0 classes and css rules. By default it is Ext4 (not Ext5) for JS, and x4- for CSS.
To use sandbox include ext-all-sandbox.js file from build directory.
It won't work. The javascript files will clash with each other.
My client purchased a Joomla component, the comoponent need a customization in both front end and back end.
But his requirment is, custom code in front end and back end to be upgrded while upgrading original component.
Example : I bought a component from a company XYZ and the component name is joomla_events, current latest version is 2.0. I done the customization in the version 2.0. Later on the company releases new version 3.0, If the client upgrade the component from version2.0 to version 3.0 then the custom code in the version 2.0 also updated in version 3.0
Please help to do the custom code upgrade in Joomla component.
This is why editing core files is never recommended, because it gets overridden when updated and people then start to have problems.
A simple answer to your question is, you can't have the custom code you added into version 2.0 appear in version 3.0.
You will need to re-add the code you added before. Yes, it is pain taking and annoying, however you would have been better in the first place to develop a plugin which could have been used to extend the component and would make upgrading easy. Not only will you have to add your code again, but you will need to thoroughly test it to ensure it works.
check this may be it helps you....
http://docs.joomla.org/J2.5:Managing_Component_Updates_(Component_release_files)
i want to port my application to CodeIgniter but i am wondering whether i should use their v2.0 or v1.72 (then when they release 2.0, upgrade it).
i have never used a framework before so i don't exactly know what implies when upgrading a framework: what does it mean practically - i just move the folders and it will work? or do i have to change a lot of settings, file structure etc? could someone enlighten me about the upgrade process.
and what would you use: v.1.72 or v2.0?
if i'm using the latest version, is there a good documentation for it somewhere so you can read about how to use the new features: packages, drivers and so on.
thanks
You can read about some of the changes in 2.0 here.
I would image the upgrade process should be straightforward as long as you do not use any features that are different/removed such as plugins. Just take your models, controllers, etc and drop them into the 2.0 framework. Then regression test you whole app, fixing any problems as you see them...
If you are selling this app or making something mission critical then of course v1.7.2 is the best choice. That said I have PyroCMS running on v2.0 and since some of my bug-fixes were merged it seems stable enough.
One should consider time frames for deployment:
If it is one week, then stick to v1.7.2
If it is three months, go with v2
Assuming three months is approximately to time for a release to stabilise?