65

You're underestimating the impact of backwards compatibility; your estimate that all active projects would migrate in 3 or 4 years is far too optimistic. Suppose I'm a PHP developer. PHP has flaws, but I know how to work around those flaws - that's part of the reason I get paid as a PHP developer. Now suppose that PHP 8 comes out and fixes those flaws, ...


44

Relying on an installed JRE to be correct doesn't make sense outside of a controlled corporate environment where all the desktops are locked to a specific version. In which case, you should ask this question of the person who controls that environment. For a mass-market Java desktop application, you should use an installer or launcher that bundles the JRE ...


25

It sounds fine, but rarely works out in practice; people are extremely reluctant to change running code, and even for new, green-field projects they are very reluctant to switch way from a language/version that they already know. Changing existing, running code that "works fine" is not something that ranks high on any project's priority list. Rather than ...


18

To quote MSDN: The .NET Framework 4 is backward-compatible with applications that were built with the .NET Framework versions 1.1, 2.0, 3.0, and 3.5. In other words, applications and components built with previous versions of the .NET Framework will work on the .NET Framework 4. However, in practice, this compatibility can be broken by ...


18

As far as I can tell, this question has been answered by Bertrand Meyer himself, and the answer is, this statement is not accurate. With classical approaches to design and programming, there indeed can be a way to write modules that are both open and closed. To find this out, you need to study second edition of this book (published nine years later, in 1997)...


17

You're making a lot of assumptions about human behavior. If you change it too much, people will evaluate your competitors, since they're going to have to spend significant effort switching anyway. For open source languages, people will just fork the old version. Look at python for an example. 3.x has been available for four years, and still isn't widely ...


15

bash has been around since 1989, and its syntax is largely compatible with that of the much older Bourne shell, which was released in 1977. Huge swaths of core functionality in many operating systems (most Linux distros, OS X, and indeed most POSIX-compatible operating systems), and many real-world systems (make systems, automated tests, initialization ...


12

Java 6 is unsupported by Oracle, so don't use that. Java 7's support ends on April 15th, so you know. Just use Java 8 and save yourself the hassle. See Oracle's support roadmap for more info.


10

You might have a look at the PNG file format and how it handles version compatibility. Every block has an id describing what kind of block it is, and it has some flags that tell the software what to do if it cannot understand that id. For example "you cannot read the file if you don't understand this block", or "you can read the file but not modify it", or "...


9

For any language other than PHP I'd say, yeah, that absolutely makes sense! That's exactly what Python is doing with the switch to Python 3. However, the problem with PHP is that there are too many flaws with the language design itself, thus what you're calling "PHP 8" would be a completely different language. And if you'd have to switch to different ...


9

You focus on syntax changes to a language. Syntax changes are fairly easy to pull off in a backwards-compatible manner: The new syntax would have been illegal in previous versions. This is why new language features often reuse keywords or introduce contextual keywords. The new features have to be enabled explicitly, either as a feature switch in the source ...


7

You're doing it right. You're stamping data with its version, which means you have a definite interpretation of it. The only open question is how to handle "old" data. Your choices are essentially between upgrading data where it lives, having your code adapt the data in realtime, or having the code handle multiple data versions. From 30+ years experience,...


6

If you are going to switch anyway, you should really consider going with PDO instead of MySQLi. The main benefit, would be that your application would be able to work with any of the 11 other database backends supported by PDO, with minimal fuss. This might not be a priority for you, but since this is an open source application there's little reason to ...


6

Language stability is not a technical decision. It is a contract between the language author and the users. The author advertise a given version as more or less stable. The less stable a language is, the more changes the author can make. Each user interested by the language can decide if he wants to invest time in it to learn new features or develop ...


6

If I understand you right, you'd be implementing the adapter pattern to isolate the API calls from the rest of your application. So when the time came to switch from v1.0 to v1.1, you'd just modify your API wrapper implementation to make different calls and the rest of your application wouldn't know or care. So your application structure would look ...


6

Insofar as the ancient question "what browsers should I support" the only good answer is "look at your traffic stats; combine with understanding of expense of what to support and make a rational decision." Anything else is ineffective. My take on the recent Microsoft action is it is more fluff and PR than anything real. The folks who are still on IE6 are ...


5

Disclaimer: I manage a ColdFusion user group. ColdFusion suffers the same problems: loved by many, despised by many. In addition, tons and tons of FUD based on pre-Java versions. ColdFusion 10 came out last year, is a huge seller and last week I signed up to test the pre-release of version 11. Also, there are two major open source alternatives, one is ...


5

Be aware that languages change throughout their life, regardless of how well it might be designed up front. Instead of trying to immediately ship the most awesome language on earth, first try to be useful and extensible. A mediocre langauge which I can actually use is worth more than any wonderful programming language that only exists in theory. Consider ...


5

In Python, it's "Easier to ask for forgiveness than permission" - it is common "Pythonic" practice to use exceptions and error handling, rather than e.g. if checking up-front ("Look before you leap") to handle potential problems. The documentation provides a few examples that demonstrate where the latter can really cause problems - if the situation changes ...


5

If I had a dollar for every time I heard "It will be dropped in X months, don't bother"..... But in your case you are the person who decides how long to maintain the version and how much work to put into it. Have you got lots of paying customers on 0.6 who will not bother to upgrade? Does it cost you lots of money to spend time on the old version? What ...


4

There's a tradeoff here; some bugs REALLY need fixing, but some things can't be changed without breaking someone's code somewhere. I seem to remember someone stating as a "rule" that every bugfix will break someone's project, no matter how obscure or obviously-broken the bug is, someone will be using it for something. Such is the nature of programmers. This ...


4

An explicit check of the callback's ability to handle parameters is about the best you're going to be able to do. Python may be loosie-goosie in its duck typing, but it will complain and raise a TypeError exception if you feed a function the wrong number of parameters. No ifs, ands, or buts about that. You have existing functions in the field that you don't ...


4

Almost all changes are, by their very nature, forward incompatible: If I fix a bug and release patch, then downgrading will introduce that bug. If I introduce a new feature, then downgrading will remove that feature and so potentially leave the code in a non-compilable state. If I make a breaking change, then that change will be breaking in either direction,...


3

No, it's not an unusual requirement. It's common to expend significant effort to make upgrades as seamless as possible for the customer, sometimes even going so far as to purposely retain bugs that client software depends on. I've had similar requirements even in environments where upgrades are done quickly with a script, even if the dual code is only in ...


3

Looking at http://dev.mysql.com/doc/refman/5.6/en/connector-net-versions.html, I guess you don't need version 3.5, version 2.0 should be enough (which is much smaller and part of 3.5). If nothing else helps, you could try to compile the connector by yourself against FW 4.0, see http://dev.mysql.com/doc/refman/5.6/en/connector-net-installation-source.html


3

that is a decent system besided the code bloat for upgrading data my advise is to upgrade as much as possible while remaining lazy about it (you read a object from a previous version->you overwrite it with the same (now upgraded) object from the current version) but you will run into trouble if you ever tighten up the data invariants or simply do a ...


3

A way of doing this can be by using a base class and interface with the basic functions for your file handling. Then use classes for each version that extend from the base class to handle all version specific cases. Functions that can change can be virtual in you base class of abstract if there are only version specific implementations. When you need a class ...


3

First, your users are typically not interested in your technical issues. They want a working software, nothing else. Note further that just because you think a feature is not important, your users might have a different opinion about that. Second, if you can afford to strip any features from a software in a new release depends on your business model and ...


3

How do i ensure compatibility between A,B and C given the fact that they are all developed by different teams? Your build tools or version control system cannot do this for you. You need integration tests for this, ideally a fully automated integration test suite. How often you run this suite depends on your team, the minimal requirement is once before ...


Only top voted, non community-wiki answers of a minimum length are eligible