This is perhaps not the exact answer you are looking for, but I can't imagine many people are developing extensions for older versions.

###Just upgrade, its inevitable anyway

The obvious solution is for the 1.5 customer to upgrade to 1.7 (1.5 is a horribly broken release anyway).

###But if you must

If we had to tackle it, it would just be a case of backing up the module with a secondary foundation module to back-port the core functionality that you require. Then when the time comes to upgrade, the dependency module could merely be deleted/removed.

The downsides being that you could potentially end up overriding abstract classes merely to add/modify a single function. The time invested in this could well be on par with just upgrading the store to begin with.

In terms of making extensions backwards compatible - it seems an odd practice - as you be making compromises for newer releases. Extensions tend to age naturally, so that rather being back-wards compatible; you develop upon it to make it forwards compatible.

If you've ever looked at the source code of 3rd party modules; they tend to be filled with Mage::getVersion() calls and conditional statements - all to be multi-version compatible. Its messy and should be avoided. In all reality - you should have different versions of extensions, for different versions of Magento. Otherwise you'll be faced supporting an extension that has deviations in class methods and an increasing number of conditional statements.

###Although here's a good example of why not

I understand your logic. But what happens in cases such as the 1.4.1 > 1.4.2 upgrade and the EAV sales tables were dropped. Any newer functions operated on the basis of this table now being flat - so trying to back-port this is far more hassle than its worth. This may be an extreme and you'll clearly make a judgement call on how much time to invest.

The latest version of Magento is forever going to be a moving target and given the choice between making new modules work with older stores - or older modules work with newer stores. I know what we'd rather do. Deprecation of functions is slow and graceful and you have plenty of time to make them newer.

This is perhaps not the exact answer you are looking for, but I can't imagine many people are developing extensions for older versions.

Just upgrade, its inevitable anyway

The obvious solution is for the 1.5 customer to upgrade to 1.7 (1.5 is a horribly broken release anyway).

But if you must

If we had to tackle it, it would just be a case of backing up the module with a secondary foundation module to back-port the core functionality that you require. Then when the time comes to upgrade, the dependency module could merely be deleted/removed.

The downsides being that you could potentially end up overriding abstract classes merely to add/modify a single function. The time invested in this could well be on par with just upgrading the store to begin with.

In terms of making extensions backwards compatible - it seems an odd practice - as you be making compromises for newer releases. Extensions tend to age naturally, so that rather being back-wards compatible; you develop upon it to make it forwards compatible.

If you've ever looked at the source code of 3rd party modules; they tend to be filled with Mage::getVersion() calls and conditional statements - all to be multi-version compatible. Its messy and should be avoided. In all reality - you should have different versions of extensions, for different versions of Magento. Otherwise you'll be faced supporting an extension that has deviations in class methods and an increasing number of conditional statements.

Although here's a good example of why not

I understand your logic. But what happens in cases such as the 1.4.1 > 1.4.2 upgrade and the EAV sales tables were dropped. Any newer functions operated on the basis of this table now being flat - so trying to back-port this is far more hassle than its worth. This may be an extreme and you'll clearly make a judgement call on how much time to invest.

The latest version of Magento is forever going to be a moving target and given the choice between making new modules work with older stores - or older modules work with newer stores. I know what we'd rather do. Deprecation of functions is slow and graceful and you have plenty of time to make them newer.

I know this won't help, but I can't imagine many people are developing extensions for older versions.

The obvious solution is for the 1.5 customer to upgrade to 1.7 (1.5 is a horribly broken release anyway).

Otherwise, if we had to tackle it, it would just be a case of bulking up your module with a secondary foundation module to backport the core functionality that you require. Potentially, you'll end up overriding abstract classes merely to add/modify a single function.

  The time invested in this could well be on par with just upgrading the store to begin with.

In terms of making extensions backwards compatible - it seems an odd practice - as you be making compromises for newer releases. Extensions tend to age naturally, so that rather being back-wards compatible; you develop upon it to make it forwards compatible.

If you've ever looked at the source code of 3rd party modules; they tend to be filled with Mage::getVersion() calls and conditional statements - all to be multi-version compatible.

This is perhaps not the exact answer you are looking for, but I can't imagine many people are developing extensions for older versions.

###Just upgrade, its inevitable anyway

The obvious solution is for the 1.5 customer to upgrade to 1.7 (1.5 is a horribly broken release anyway).

###But if you must

If we had to tackle it, it would just be a case of backing up the module with a secondary foundation module to back-port the core functionality that you require. Then when the time comes to upgrade, the dependency module could merely be deleted/removed.

The downsides being that you could potentially end up overriding abstract classes merely to add/modify a single function. The time invested in this could well be on par with just upgrading the store to begin with.

In terms of making extensions backwards compatible - it seems an odd practice - as you be making compromises for newer releases. Extensions tend to age naturally, so that rather being back-wards compatible; you develop upon it to make it forwards compatible.

If you've ever looked at the source code of 3rd party modules; they tend to be filled with Mage::getVersion() calls and conditional statements - all to be multi-version compatible. Its messy and should be avoided. In all reality - you should have different versions of extensions, for different versions of Magento. Otherwise you'll be faced supporting an extension that has deviations in class methods and an increasing number of conditional statements.

###Although here's a good example of why not

I understand your logic. But what happens in cases such as the 1.4.1 > 1.4.2 upgrade and the EAV sales tables were dropped. Any newer functions operated on the basis of this table now being flat - so trying to back-port this is far more hassle than its worth. This may be an extreme and you'll clearly make a judgement call on how much time to invest.

The latest version of Magento is forever going to be a moving target and given the choice between making new modules work with older stores - or older modules work with newer stores. I know what we'd rather do. Deprecation of functions is slow and graceful and you have plenty of time to make them newer.