66

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

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 ...


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 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 ...


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

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

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 ...


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

I have done it and it's possible, though there are a few pitfalls around autoloading to consider. I described the approach in a blog post: PHP: Using class_alias to maintain BC while moving/renaming classes Summary: Do not put the class_alias() code into the original class file The problem is that type hints do not trigger the autoloader. Similar to ...


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

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 ...


3

In such cases, you need to keep track of users with app version. Whenever you are making any changes in database schema, if any of the user is using previous version, don't delete the column name. You can do only when there is no any user using that version. For managing multiple App version, you need to work more on APIs. You can handle such cases by using ...


3

Application should be planned from the start for backward compatibility, so any new version shall not remove old feature (or remove columns the DB schema). This way you guarantee new version will always work with old DB. But if you need only sync certain data, you may add synchronization adapter for every version to unify data exchange between them without ...


3

I don't know Julia enough to know if the following can be applied to your situation in full, but to give you a general answer for comparable situations: IMHO it is a good idea to avoid maintaining two different code bases of the same package over several months. If the majority of your users is still using Julia 0.6, and you expect them to do so over a ...


3

Given this licensing model, you need to provide indefinite front-end support unless you want to force customers to upgrade their back-end (or switch to a competitor.) One option would be to support only a limited number of historic back-end APIs with the front-end app but provide legacy versions as separate apps. Users will have to install a legacy version ...


3

I will assume that it is unspecified if HeavyFoo::add returns (a reference to) a HeavyFoo or a Foo object. If that is the case, then technically you haven't changed the interface and don't need to bump the major version. The users that are relying on getting the lightweight object are relying on undocumented behavior. On the other hand, if that undocumented ...


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