backwards-compatibility

So far, I've been merely using YARV (ruby 1.9) as merely a faster implementation of ruby than ruby 1.8, and ensured that all of my code is backwards-compatible with ruby 1.8.6. What circumstances, if any, are stopping you from writing 1.9-specific code? One reason per answer. neutrino Also, if we're talking about rails, then the problem there is the compatibility of gems/plugins with ruby 1.9. I'm sure everyone who wants to upgrade to 1.9 keeps an eye on isitruby19.com The first release candidate for Ruby 1.9.2 is due end of May and I believe many are waiting for 1.9.2 to hop on the 1.9 train.

32-bit application executables contain machine code for a 32-bit CPU, but the assembly and internal architecture (number of registers, register width, calling convention) of 32-bit and 64-bit Intel CPU's differ, so how can a 32-bit exe run on a 64-bit machine? Wikipedia's x86-64 article says: x86-64 is fully backwards compatible with 16-bit and 32-bit x86 code. Because the full x86 16-bit and 32-bit instruction sets remain implemented in hardware without any intervening emulation , existing x86 executables run with no compatibility or performance penalties, whereas existing applications that

By now all Mac App Store developers know that all apps must have the new OSX Lion Sandboxing enabled going forward. For existing apps, we must enable it in XCode 4.2 and set in place the data migration plist. So my existing Mac App Store app has a build target of OSX 10.6.8 Snow Leopard. Not only that, but it does access the webcam and also synchronizes stuff to iCal via CalendarStore API and AppleScript. I'm expecting most of my app to break when I enable the Sandbox, but when I get that working in the Sandbox I'm wondering if a Sandboxed app can run in Snow Leopard. Does anybody have

The final committee draft of the upcoming C++0x standard says: Every C header, each of which has a name of the form name.h, behaves as if each name placed in the standard library namespace by the corresponding cname header is placed within the global namespace scope. It is unspecified whether these names are first declared or defined within namespace scope (3.3.6) of the namespace std and are then injected into the global namespace scope by explicit using-declarations (7.3.3). Earlier C++ standards read similarly. My question is, when the C++ header #include<cname> uses overloaded functions,

I am curious to understand/figure-out if the ECMAScript-6 new-changes will work on the old browsers or not. Why I am asking this question is: I remember the introduction of 'use strict'; in ECMAScript-5, it was meant for the compatibility with the old versions. That means the old browsers will keep working fine and they will just ignore it when they encounter the 'use strict'; statement while parsing the new JavaScript code. And the new JS-engines will treat the statement 'use strict'; in some special way as detailed here Strict mode . So, coming to the question I seriously doubt and curious

I have a project that uses generics and a few Java 1.5/6 bits and pieces. Is it possible to compile this code to work on a system running a 1.4 JRE? I use an ANT build script and javac task to compile the library. This builds fine while the target attribute is 1.5. If I change the target to be 1.4 I get the following error: generics are not supported in -source 1.4 (use -source 5 or higher to enable generics) So I add a source attribute and try a value of 5 and 1.5. New error: javac: source release 5 requires target release 1.5 Am I going to have to go through all my code and change the 1.5

I have to work an an old application that used binaryFormatter to serialize application data into filestream (say in a file named "data.oldformat") without any optimizazion the main class has been marked with attribute <serializable()>public MainClass ....... end class and the serialization code dim b as new binaryformatter b.serialize(mystream,mymainclass) In an attempt to optimize the serialization/deserialization process I simply made the class implement the ISerializable interface and wrote some optimized serialization routines <serializable()>public MainClass implements ISerializable ....

I have built an iPhone app with SDK 4.2 however I know also want to make it compatible with iOS 3.1.3. First step was to set the Deployment Target to 3.1.3. It runs fine on the 3.2 Simulator but the app crashes at times since I'm using some methods which are not available in this early SDK. So my qestion is, is there a straight forward way to locate the offending methods/classes I'm using in my project which are not available in 3.1.3 ? (without manually going through each method call and consult with the docs for the SDK availability?) Thanks. UPDATE: I have executed the app on 3.1.3 and