When the developer of an API, e.g., Microsoft, Apple or me, announces a feature of the API is being deprecated, how long should the API developer wait before removing the feature from the API?
From the other point of view, how long should a user of an API expect to have to refactor code after an API feature is marked as deprecated?
If you move from version A to B, you should directly remove deprecated methods.
Unless you know that you won't need later upgraded version then you may keep what's working.
But as every problem, the sooner you take them on, the easier it'll be.
It's usually easy enough to change deprecated code from version A to B, but if you cumulate modifications, it'll be a nightmare
Once you discover APIs that are marked as deprecated, you should start looking to update your software to replace them with non-deprecated methods. If you continue to use them, you run the risk of your software not working on newer versions. This is fine if you never plan on upgrading, as evidenced by the multitude of Win 3.1 software still in use. However, if you are going to be supporting the software or releasing new versions, you should update as soon as feasible.
Usually, the API never removes features due to the fact that some programs will be rendered useless if they rely on a certain method. But if the method is honestly useless or contains a lot of bugs, they remove it after two or three updates.
Related
I am extremely new to mobile developing and have recently been put in charge of updating a React-Native app using Expo, that hasn't been touched in about 18 months.
I am familiar with creating web applications or websites from scratch and thinking about debugging from a creation standpoint with updated code that is not deprecated but the idea of updating old code is foreign to me.
Can someone help share their thought process when it comes to this?
The mobile app itself runs alright - crashes and malfunctions from time to time.
Is the idea to go in and see what code is deprecated and which dependencies need to be updated? And/Or is the idea to try and find what is making the code crash and malfunction and leave deprecated code and old dependencies?
Thanks for your patience with what seems like a silly question.
And/Or is the idea to try and find what is making the code crash and malfunction and leave deprecated code and old dependencies?
It is typically recommended that crashes and malfunctions should be resolved before updating libraries. Some libraries may introduce further crashes and errors after upgrade due to breaking changes and deprecation. As such it would be difficult to separate code bugs from errors caused by library upgrades.
If some of the bugs and crashes cannot be resolved without library update, then fix as much as you can before updating the library.
Is the idea to go in and see what code is deprecated and which dependencies need to be updated?
This question is subjective. It depends on how much time can be spared for the upgrade process. Obviously, updating libraries can have other small benefits like improving performance or reducing code size etc, but if a library that is used extensively in code (eg. react-navigation) has not been updated for many major releases then update/ refactor and testing will take a long time and may not be worth the time if nothing is broken.
Furthermore, it is easier to update libraries regularly and frequently rather than wait for the current version to be deprecated. This way, we avoid having to deal with tons of breaking changes in one go.
We are using webdriverIO version 4 in a quite a few frameworks where I work. While undertaking the review of one of the frameworks, the option of upgrading to version 5 was recommended. However, the framework is not the most straightforward and there will be a lot of manual fixes needed to commands in many places and the time needed for it is just not known.
Hence the question, what is the risk if we don't upgrade webdriverIO at all? Any dependencies stopping successful builds or browser version incompatibilities affecting test execution? And how soon are these likely to be realised.
Any pointers that can enable this review will be great help.
One of the major risks of not updating over the long-term is Node version support dropping. As new versions of Node are released, you'll likely want to upgrade to the latest. However, since older versions of WebdriverIO won't be tested on these new Node versions, there may be incompatibilities between the two.
Apart from that, other drawbacks include:
Missing out on important new features. For example, WebdriverIO v6 includes 'waits' by default now, so you no longer have to include so many "waitFor" commands, and your tests will be less brittle.
Security Updates via dependencies. While not as important, considering tests aren't normally public facing, it's still nice to have the latest features available.
Unable to make feature requests. There's a very low chance that you'd be able to get any new features added to old versions of WDIO, especially v4. This means you'd have to do it all yourself.
Less likely to get help. If something breaks or you're in need of outside help, being on an older version will hinder any help others can provide as they'll be much less experienced with it.
I've upgraded many test suites from 4 -> 5 and while it wasn't the easiest transition, it was also very doable. Unless you have something very complicated going on, I'd put the upgrade at a week tops. It took me about a work day or two to update mine, but it wasn't the most complex code (on purpose).
Apple introduced Xcode source editor extensions with Xcode 8.
Will Xcode 8 still support plugins served via Alcatraz?
Xcode 8 prohibits code injection (the way plugins used to load) for security reasons. You can circumvent this by removing the code signing on Xcode. Both of these tools are capable of simplifying that:
https://github.com/inket/update_xcode_plugins
https://github.com/fpg1503/MakeXcodeGr8Again
To work on Xcode 8+ without removing the code signing, plugins will have to be rewritten as Xcode Source Editor Extensions. Unfortunately, the APIs for these extensions only allow for text replacement at the moment, so they are not an adequate replacement.
I've filed a report on rdar, do not hesitate to express your mind as well:
Xcode is a primary tool for the development on all Apple platforms.
People can either love or hate it, the fact is it's still the most
powerful development tool around.
Lots of its power and usefulness has been achieved by 3rd-party
plugins, later covered by the Alcatraz project, which is the number
one extension management system for Xcode, as vital and needed as for
example npm is needed for Node.js. It's all based on a fair, aware
community developing its helpful open-source extras and publishing
them on GitHub. It's not a code-injecting ghetto targeting infecting
stuff. It's a community within a community.
Xcode 8 tends to drop support for these plugins, most often being
narrated as a security step in favour of preventing distribution of
injected stuff. This is false; you simply can't prevent that 'cause
there's always someone who finds the way. This step simply makes Xcode
was less usable, complicated and not that feature-rich. There are many
important plugins which developers love, contribute and move forward
to make Xcode even better, tell yourself honestly, mostly even better
than you could in a short period.
The community needs powerful stuff. Way more powerful than basic
source-editing magic. Please reconsider this step in a spirit of
community and support to your developers.
In last years, there's a move towards closing your platform. First
shutting down Spotlight plugins and its great Flashlight plugins
manager, which is simply great and now I need to disable Rootless to
use it. Now it's Xcode plugins. You're doing more and more to make
developers and power users feel sad and not having their computing
device in their hands.
There's a detailed discussion on Alcatraz repo, it says everything:
https://github.com/alcatraz/Alcatraz/issues/475
I'm attaching a list of great plugins I simply can't spend a day
without:
AxeMode – Xcode issues patching Backlight – active line highlighting
ClangFormat – code formatter DerivedData Exterminator – daily need
getting rid or bad stuff FuzzyAutocomplete – name says it all, still
more powerful than Xcode completion HighlightSelectedString MCLog –
console log filtering, including regexes OMColorSense Polychromatic –
variables colouring, cute stuff RSImageOptimPlugin – processing PNG
files before committing SCXcodeMinimap – love this SublimeText-thingy!
XCFixin_FindFix – fixing Find features XcodeRefactoringPlus – patching
Refactor functionality, still buggy, but less than Xcode without
plugin XToDo – TODOs collection ZLGotoSandbox – 'cause dealing with
your folders would be a hell without it
Most of them are not source code-related, thus deserve having a way to
be loaded and working like a charm again.
You can certainly load all your plugins by recode signing Xcode 8.0. All credits to the XVim team. They seemed to solve this problem.
https://github.com/XVimProject/XVim/blob/master/INSTALL_Xcode8.md
The Most Important Step From The Solution
There is no support and we can't expect any. Apple decides to shut down the ecosystem around the Alcatraz package manager before they have an api ready (extensions) that is able to do what the plugins were doing before. The extensions are currently limited to the text frame which does not allow to do much.
The main reason announced by apple is security and we can now disable code signing with effort to get back the most important features that were missing in Xcode.
Bad day for the community, bad decision from apple.
I also recommend the discussion on Alcatraz here: https://github.com/alcatraz/Alcatraz/issues/475
Most importantly if you want to support Alcatraz file a bug at http://bugreport.apple.com to make them aware that many people are suffering with this change
I did the same (openradar.appspot.com/28423208):
Xcode is a primary tool for the development on all Apple platforms.
People can either love or hate it, the fact is it's still the most
powerful development tool around.
Lots of its power and usefulness has been achieved by 3rd-party plugins, later covered by the Alcatraz project, which is the number
one extension management system for Xcode, as vital and needed as for
example npm is needed for Node.js. It's all based on a fair, aware
community developing its helpful open-source extras and publishing
them on GitHub. It's not a code-injecting ghetto targeting infecting
stuff. It's a community within a community.
Xcode 8 tends to drop support for these plugins, most often being narrated as a security step in favour of preventing distribution of
injected stuff. This is false; you simply can't prevent that 'cause
there's always someone who finds the way. This step simply makes Xcode
was less usable, complicated and not that feature-rich. There are many
important plugins which developers love, contribute and move forward
to make Xcode even better, tell yourself honestly, mostly even better
than you could in a short period.
The community needs powerful stuff. Way more powerful than basic source-editing magic. Please reconsider this step in a spirit of
community and support to your developers.
In last years, there's a move towards closing your platform. First shutting down Spotlight plugins and its great Flashlight plugins
manager, which is simply great and now I need to disable Rootless to
use it. Now it's Xcode plugins. You're doing more and more to make
developers and power users feel sad and not having their computing
device in their hands.
There's a detailed discussion on Alcatraz repo, it says everything:
github.com/alcatraz/Alcatraz/issues/475
I'm attaching a list of great plugins I simply can't spend a day without:
AutoHighlightSymbol - Add highlights to the currently selected token
ClangFormat – code formatter
DerivedData Exterminator – daily need getting rid or bad stuff
FuzzyAutocomplete – name says it all, still more powerful than Xcode completion
KZLinkedConsole - be able to click on a link in the console to open the relevant file and be faster to debug
PreciseCoverage - nicer gui than xcode provides to view the coverage
XcodeColors - shows colors in the console depending on log level (how else should a console be used?)
Most of them are not source code-related, thus deserve having a way to be loaded and working like a charm again.
If you do not make a fast step to support your community i'm sure we
will find another platform to work with.
Seems like this should work. Found some answers here:
https://github.com/alcatraz/Alcatraz/issues/475
The key seems to be to removing code signing in order to get existing plugins to work.
Apparently not :'(
https://github.com/alcatraz/Alcatraz/issues/475
We have to wait until someone convert the plugins into the new Xcode Extensions
I recently asked a question on updating programming packages (on systems that provide programmer tools via packages) for which there has been no response. This leads me to ask the following question. As a software developer over the years, I've encountered enough bugs in tools that lead me to want to keep at the most recent stable release/update. The important caveat being that near the release date of a component, only clearly necessary changes are introduced. I would like to get a better understanding of the spectrum of how developers deal with new releases to the tools they use. So what do YOU do? Monitor mail lists and update to new releases after careful analysis or on a whim? Take whatever releases project management provides/permits? Out of desperation in response to a gnarly bug you're trying to fix? Something else entirely?
I would like to get a better understanding of the spectrum of how developers deal with new releases to the tools they use. So what do YOU do?
I grab the final release of the new tools as soon as it's available. That is in my private environment.
At work there is often just one specific version which is bought and expected to be used for several years. Developers cannot influence that.
At home I develop in Xcode. I maintain at least 2 versions of the environment, the current official release and the latest beta release. Both versions are kept up to date. If there are any issues with any of my projects and a new release of Xcode, I fix the issues with my project. Under no circumstances will I keep an older environment around for compatibility reasons. Most of my development is done against the stable API unless I need a feature from the beta API. All testing is done in both environments, so that hopefully I'll be able to catch bugs related to API changes as soon as possible. I don't know if I should credit my mad development skills or the quality of Apple's releases, but I rarely encounter any issues with API/SDK changes.
At work I develop in Visual Studio 2005 / Windows XP. It's horrible and there's nothing we can do about it.
I'm writing a small free tool. It's currently in Beta testing using .NET 3.5 but there's at least one aspect from .NET 4 I'd like to incorporate.
So, is it jumping the gun a bit to release .NET 4 based software?
Thx!
Wait till atleast the public release of .NET 4.0 before releasing anything other than early beta software with it.
I'm excited about alot of the new stuff too, but beta software built on a framework that is itself in beta is a recipe for disaster if you ask me.
Writing code for 4.0 might make sense. Releasing for general consumption prior to its official release seems foolish to me. Minor changes in 4.0 between now and the official release could cause your code to break. It would likely be easy to fix, but until you do your users are mad at you for putting out (what appears to them to be) a buggy program.
I read somewhere that VS2010 comes with a go-live license, meaning you can. Not sure I would, though. (See other answers...)
Well, you'd be forcing people to download and install Beta software. People may be reluctant or even unable to do this so, if nothing else, you're limiting your audience.
Also anything built with the Beta software isn't guaranteed to be compatible with the final released version.
I wouldn't go for the full framework, but including libraries like the CTP for the Task Parallel Library if your application is heavily multithreaded would be OK since you can just ship the .dll with you application and your users won't have to download anything. However, even with the TPL I would watch out, it's quirky and can slow your algorithms by an order of magnitude on things that should seemingly run just fine. The CTP is already over a year old though.