backwards-compatibility

问题 I just came across "WTF" sort of error: I updated one of my classe's methods and added one method too. After running my program, this is what popped our when program tried to open and unserialize recently saved data (before the methods changes): java.io.InvalidClassException: cz.autoclient.settings.Settings; local class incompatible: stream classdesc serialVersionUID = 2404650814140543454, local class serialVersionUID = 4256355437298300223 According to what java documentation says about that,

问题 I have an Android app that's been on the market since v1 of the OS. I haven't touched it since and thus forgot all that there was to forget about developing for Android. With the new Android 2.3 SDK, can I compile my app so that users of previous OS releases can also use it (say 1.6 or 2.1)? 回答1: Sure. Just put minSdkVersion in your Manifest. 回答2: Android has changed A LOT since the very first version. many things have been deprecated or aren't supported anymore. You should check what's you

问题 I was wondering about providing backwards compatibility by using optional parameters. In my program I have an interface with a function that is used throughout my program as well as in a lot of unittests. For some new functionality, a boolean has to be passed into this function which will alter its behaviour if set to false . If you pass in true , you will get the same behaviour as before. Now I have to pass in true everywhere where in my current code where I have called this function before.

问题 Our current environment is .NET 3.5 SP1 but we're in the process of migrating to .NET4 and Visual Studio 2010. I would like to stick to using .NET 3.5 for the deployment/production environment however use Visual Studio and TFS 2010 for development, until the production environment is cleared for upgrade to .NET4. Is this possible (I assume yes :B), and how? What I have tried is changing the TargetFrameworkVersion in the project settings to "v3.5". However, I get a build failure due to the

问题 My development environment is running in JDK1.6, and I need to compile some classes so they are compatible with a client running JDK1.5. How would I do this with the 'javac' ant target? 回答1: Command line : javac -target 1.5 sourcefiles Ant: < javac srcdir="${src} destdir="${build}" target="1.5" /> 回答2: <javac source="1.5"... /> 来源： https://stackoverflow.com/questions/169044/how-to-compile-classes-to-jdk1-5-when-ant-is-running-in-jdk1-6

问题 This is a specific gcc related question. I have a library compiled with g++ 4.1.2 that I want to give the user. The user can use our API in their code and link our library to create the final executable. The question I have is related to g++ version compatibility. Some of our users are using g++ 4.4.3, others 4.3.3, and still others 4.2.1. Is the library compiled with 4.1.2 compatible with all these g++ versions? My guess is they should be because they are ABI compatible. But some of our

问题 We have a dll with version 1.0.1.* that is used by many applications whcih themselves run on different machines. This dll resides in the GAC of the machine running the application. The application includes this dll as a reference with "Specific Version" set to false. We have come up with version 1.0.2.* of this dll which is backward compatible. Is there a way to deploy the new dll and ask all the applications to pick the latest version without having to recompile the applications. I am aware

问题 Am surprised there's 3 different forms: RawConfigParser , SafeConfigParser and ConfigParser (docs). I read the differences but why isn't everyone using SafeConfigParser , since it seems, well, safe? I can understand that in the case for Python 2 that the other two were kept for backward compatibility. UPDATE : In Python 3.2, SafeConfigParser has been renamed to ConfigParser, and the old ConfigParser has been removed (source: NEWS for Python 3.2). 回答1: In short, use configparser

问题 When starting with a package versioned at 1.0.0 in an API bundle, what should the new version be after adding a new interface to said package? The whitepaper makes this statement regarding compatibility: It should be obvious that binary compatibility plays an important role in backward compatibility. However, backward compatibility is also very dependent on the semantics. If the responsibility of an interface changes it could still be binary compatible but no longer be backward compatible. At

问题 According to the instructions found here, to make your app state which screen sizes you can support, you'll need to compile your app against Android 1.6. Using the minSdkVersion and targetSdkVersion this should run also on Android 1.5: <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"/> However, when I try to launch my app from Eclipse to run in a emulated 1.5, I get the following error: Failed to find an AVD compatible with target 'Android 1.6'. Is this an error of the eclipse