So I have an app I created about 2 years ago. And honestly it never sold that well so I trashed the source code on it. Well recently I have taken an interest in updating the app. Can I upload a new version that is not from original source code? Do I just need to name with it with the same bundle identifier?
Yes, you should be able to upload your new version on top of the old one, providing (of course) that the version number has been incremented and that the bundle ID is the same for the app.
Hope this helps!
Related
I need some best-practice advice for how best to go-live with a new PrestaShop store.
The background: we have been working on a new store, with new core (PrestaShop version) and new design (updated theme).
Next: very soon, we need to put this store live, but we already have a live (and active) PrestaShop store.
So, what is the best approach to get this new store live?
Of concern are the changes to the current live version whilst the new one has been developed - content, orders, accounts etc which need to persist.
FYI we have full server access with cPanel, SSH etc.
Many thanks!
Set the current live site in Maintenance for a few hours at a time when you have less visitors: use a module like [MigrationPro][1]
[1]: https://addons.prestashop.com/en/data-migration-backup/8934-migrationpro-prestashop-upgrade-and-migrate-tool.html or look for some free scripts on Prestashop forum->Free modules section (although I recommend the module above; not affiliated with them just used it several times).
Migrate the data, check if everything alright and if it is, just move elsewhere (as a backup) the files in the web directory and move there the new shop files (set the new shop on maintenance too).
Clear all caches, test it the set it online.
My opinion is:
Putting the main site in maintenance mode
Moving the main site to a new test address
Upgrading the test site in the new address to the desired version of Prestashop
Getting output from the desired template (your custom theme) and importing it on the test site
If there is no problem, you can move the test site to the main site (files and databases) or do the same thing again on the main site.
You need to start a process and create documentation.
Create a copy of the live shop folders and database to a new address like /test.
Upgrade your test shop to the new version 1.7.6.5.
Start moving your theme and modules from your new store to the upgraded test shop.
Create documentation of every change. like moving files, moving modules DB tables, and more.
Create a backup of your current live shop.
Repeat 1-3 steps and follow your documentation in your live shop.
I think you can move everything in a few hours if you have a step by step guide.
I'm a brand new to Accurev and I'm having many troubles with it. One of the developers I'm working with has promoted bad code (things are now broken that weren't before) for 2 months on a stream, and I'm wanting to get a copy of the original code before any changes were made to it.
I currently have a workspace, and whenever the other developer creates code, I pull his changes into this workspace attempting to fix the bugs. These changes are promoted to an existing issue within Accurev.
Is there any way I can perhaps create a second workspace and obtain a copy of the original code (before any changes were made)? My target date is March 14th.
I would suggest you revert or demote the bad code that was promoted into the stream (Depending on what version of AccuRev you are using). This would put the stream back into the state it was before the promotion occurred.
Below are some suggested readings on the related topics.
Best way to "un-promote" files in Accurev?
https://community.microfocus.com/borland/managetrack/accurev/w/wiki/26745/purge-revert-and-demote
https://community.microfocus.com/borland/managetrack/accurev/w/accurev_knowledge_base/25951/how-to-revert-changes-in-a-stream
https://community.microfocus.com/borland/managetrack/accurev/w/accurev_knowledge_base/26079/what-is-the-proper-way-to-revert-by-change-package
As an alternative, you could create a time-based stream below the one with the bad code. Set a time basis that predates the bad promote.
To do this, I right-clicked the stream >> New Snapshot.
I select "Specified" and enter the date (with a relative time).
From the Snapshot, I created a New Workspace which was then populated with previous code.
Hope this helps!
In my Titanium project, I have been new uncommitted changes to following files being shown in my Git status:
plugins/ti.alloy/hooks/alloy.js
plugins/ti.alloy/hooks/deepclean.js
I've never seen or touched those files and someone else in my team got them as well randomly after an update some time ago.
Are these updates to the Titanium Alloy framework that should live in .gitignore? Or should I commit them?
Those files are changed with an update of Alloy (CLI). When you work with multiple people on the same app, it will be recommited every time someone works with a different Alloy version.
You can commit it without causing anything wrong, or you can also add them to gitignore without issues (not tested, but should not cause issues).
When I update my CoreData model, it crashes the app, So I have to delete the old app, and then reinstall. That's fine with me, but my question is: How do I tell my customer that they must delete the app before they reinstall? This seems too complicated...I am just adding 1 additonal field to a models and that's it.
Is there a better way to deal with this?
Thanks
You need to set up database migration... To upgrade a customer's existing data to the newest data model when they update. For some changes Core Data can do it for you. For others you'll have to write the migration code yourself.
Perhaps start here: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/Introduction.html
Like #Nielsbot said, there's a migration system that Core Data uses.
You can create new versions of your model and select which one to use. There's a little bit of code to change in your AppDelegate method where the persistent store coordinator loads the model to tell it to load versions. I'd suggest you read Apple's documentation on how to implement this at: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreDataVersioning/Articles/Introduction.html
If you're just adding one field to a table then you can create a new version of the database. Keep the current one unchanged.
In one of the menus there is a create new data version or something.
Make the changes in the new version.
There are numerous tutorials about how to do this.
If you release an update that crashes the app then apple won't approve it so you will have to so this anyway.
I've been updating my iPad app very steadily now and the process has been fine. But in a month or so, I'm going to be upgrading it to a version that has a completely different architecture.
Both versions will be using the cache and db in very different ways to store the data it's pulling from a server.
Question: Will the Apple update process automatically delete all local data from my previous version upon installing the new version? Or, do I have to code this functionality in somewhere in my new version?
Example: Some files you download on Windows don't remove the data from "Application Data" or "Local Settings" upon uninstalling. I fear that this same scenario will happen on my iPad when upgrading my app to a completely new version. Is this the case?
Thanks,
Derek
No, the update process does not delete files that you have in the app's documents folder. They will still be there.
iPhone and iPad updates do not remove data from previous version installations of an app. Your app will have to detect (say, look for the current version number) the old databases, and either delete them, or perhaps better for the user, update them to the new format.
Make sure to somehow tag the new data format with a version number so your app can detect it, and not delete it.