I'm upgrading an old React Native app, from 0.59.1 to 0.68.0 (which is the last one). Useless to say that it's a huge pain to upgrade all of those dependencies and I'm thinking to create a new project (and move all JS files) instead of upgrading the current one.
But I have a problem: the app is currently in production and I want to make a new project which would result in an update for the old app. I think that the goal to do this is "move" the bundle ID from the previous project, but I really don't know how to do it.
Any ideas? I need tips for both iOS and Android.
Thanks in advance!
Already upgrading to 0.68? The stable version got out a few days ago and a lot of libraries (basically every library) are currently not stating in their docs where to add their dependencies etc. in 0.68 since a lot of stuff moved is added or removed... 0.68 is completely different from 0.67. I would consider to wait a bit with upgrading to 0.68 and upgrade to 0.67 for now. Also since 0.59 is a rather old version, I would take your first suggestion, create a completely new project running on 0.67, installing every package you have in your old project, regularly checking if the build succeeds and then just like you said copy your /src folder to the new project. And yes you need to change your package name to your old one. Heres a video on how to do it.
Related
I abandoned a project I was working on for a while I came back to open it on upgraded flutter and dart plugin in visual studio code windows 10.now I get so many problems. is there a way to automatically update code to solve these errors?
do these steps:
delete build folder
delete .idea folder
run flutter clean
run flutter pub get
run flutter pub upgrade
then try to run your project.
The simple answer is it depends.
Judging by the comments from a reasonably good answer by Hasan Abbasi, this wasn't enough.
Depending on how old your project is, there are 2 choices before or after doing what that answer said:
If it's any more than 2 or 3 years old, I'd probably rewrite it from scratch. In that time, Flutter and Dart have matured greatly, which involves many breaking changes. Also, null-safety has been introduced. Creating a new project after updating Flutter will also fix those Gradle issues because the configuration files will be reset.
If it's less than that, try to fix those Gradle issues either by hand or just deleting the '/android' or '/ios' etc. folders and letting Flutter/Dart automatically recreate them when you run the app next. You'll probably need to migrate to null-safety: read about null-safety so you understand it properly, then try using the dart migrate tool. You will likely need to spend some time changing dependencies for null-safe versions. Then you can try the flutter fix tool to automatically resolve SOME issues.
Hope you can get your app to work soon!
I'm migrating a typescript/angular based NativeScript project over to the latest version of NativeScript, and am running into an issue. Before, I was using the tns-platform-declarations plugin (https://preview.npmjs.com/package/tns-platform-declarations) so I could get intellisense (I'm using VS Code) for things like UITextView and other native calls. But when updating my project, this module is removed from package.json. And if I add it back in, it says my project is not compatible with 7.x.
Do I just need to wait until the plugin is updated, or is there another way to get intellisense going, but still use NS 7.x?
Extending on Matthew's answer. Make sure you are including in your tsconfig the references.d.ts file, the one that points to either tns-platform-declarations or #nativescript/types, depending on your NativeScript version.
When you migrate the project it will change your tns-platform-declaration to #nativescript/types
https://nativescript.org/blog/nativescript-7-announcement/
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 downloaded this Xcode project(version 1.0 as in contents.xcworkspacedata) from here
When I try to open it, got this error:
Failed to load project at '.../Lesson31_OSXCocoa/Lesson31_OSXCocoa.pbproj', incompatible project version.
How do I open project version 1.0 with xcode 4.2?
You're better off trying to find a newer tutorial, or just studying the code as-is, without expecting to build and run it.
Judging by the modification dates, this code is almost ten years old. Even if you can get a modern version of XCode to open it, there's no reason to think that the headers, libraries, etc., that it needs to compile and run will still be compatible. Moreover, ten years is a long time in software terms. While some of the content might still be applicable, it certainly won't be anywhere near the cutting edge (which itself won't be new by the time you've mastered it).
All that said, if you're really intent on working with that project file in XCode 4.2, the best way is probably to convert it the same way a continuously developed project would have: XCode by XCode.
You can download older versions of XCode from Apple here (requires free Apple developer account).
Some older version will be able to import that file and update it to a newer format.
Assuming you don't stop at that point and use that version of XCode, you can repeat the process with the updated project file and ever-newer versions of XCode until you've arrived at version 4.2.
Relatively easy to make a new project and add the appropriate files to it. Took less than 10 minutes (had to update the code in a few places). Note that I didn't spend much time cleaning up this old code - quite a few deprecated warnings. But it runs and works. I have Xcode 4.3.2 installed but hopefully you'll be able to open it with 4.2. Here's a link to it: Lesson31.zip
Note that the process for doing this (so you can do it for any others), is to create a new Mac OS X Cocoa Application project, add the files (except main.m) from the old project to the new project, and then add necessary libraries to fix link errors (OpenGL Framework). If there's a nib then you can open that in Xcode and copy the window with view and controller out of that project and paste them into the .xib file created with the new project. Then fix compiler warnings/errors as necessary (add a few (char*) coerces, remove reference to std::ios::nocreate which doesn't seem to be available, etc).