Backward compatibility with 5.6, 5.5, 5.4 etc
Permalink 1 user found helpful
Any addon written for versions before 5.7 will need modifying to work with 5.7 as per
http://www.concrete5.org/community/forums/5-7-discussion/5.7-add-on... etc..
So far, with nearly all my c5 addons, I have managed to write adaptive code that is backward compatible. It saves me having to maintain multiple versions of the same addon. With it likely that 5.6 will continue in parallel with 5.7 for a long time, the advantage of one set of code covering multiple c5 versions becomes even more attractive.
So here is my thought experiment that hopefully others can add detail to. Suppose current coding standards for 5.6 were flexible and the 5.6 install was made on php 5.3+, what could be done to make an addon updated to work with 5.7 run on such a 5.6 site?
Would it be feasible to make a 5.7 compatibility layer addon for 5.6 that overrode some core classes to enable 5.7 addons to install and run on 5.6? - or at least, addons coded within a limited subset of the 5.7 api?
http://www.concrete5.org/community/forums/5-7-discussion/5.7-add-on... etc..
So far, with nearly all my c5 addons, I have managed to write adaptive code that is backward compatible. It saves me having to maintain multiple versions of the same addon. With it likely that 5.6 will continue in parallel with 5.7 for a long time, the advantage of one set of code covering multiple c5 versions becomes even more attractive.
So here is my thought experiment that hopefully others can add detail to. Suppose current coding standards for 5.6 were flexible and the 5.6 install was made on php 5.3+, what could be done to make an addon updated to work with 5.7 run on such a 5.6 site?
Would it be feasible to make a 5.7 compatibility layer addon for 5.6 that overrode some core classes to enable 5.7 addons to install and run on 5.6? - or at least, addons coded within a limited subset of the 5.7 api?
Namespacing is not the only change:
- folder structure is different
- attributes have moved
- helpers have changed
- tools are gone
These are just a few. A blocks only package I suppose could pull it off....but I really doubt it.
5.7 for all intents and purposes is a completely different application all together.
ChadStrat
- folder structure is different
- attributes have moved
- helpers have changed
- tools are gone
These are just a few. A blocks only package I suppose could pull it off....but I really doubt it.
5.7 for all intents and purposes is a completely different application all together.
ChadStrat
Lots of helpers are still there and the same is true for the models. I was able to port some fairly complex add-ons in almost no time by adding namespaces and some minor changes which one could add with "if 5.7 .. else ..".
I'm not a big fan of such if else's as it makes the code pretty ugly but one could derive some add-on classes and override certain behaviours for 5.7. That's definitely possible, even if lots of things in 5.7 are different.
It's not something I'm really going for, I'm in love with git, but I'm fairly confident that I could make things easier.
I'm not a big fan of such if else's as it makes the code pretty ugly but one could derive some add-on classes and override certain behaviours for 5.7. That's definitely possible, even if lots of things in 5.7 are different.
It's not something I'm really going for, I'm in love with git, but I'm fairly confident that I could make things easier.
Those are the reasons why I was thinking about a compatibility layer the other way round.
Update a block to be nicely 5.7 compliant with all that entails. Then provide a layer to enable that 5.7 block to run on 5.6.
I am not looking for effort free forward porting, but once forward ported, for a way to have relatively effort free backward compatibility.
Update a block to be nicely 5.7 compliant with all that entails. Then provide a layer to enable that 5.7 block to run on 5.6.
I am not looking for effort free forward porting, but once forward ported, for a way to have relatively effort free backward compatibility.
I agree with ChadStrat here not just because of the massive changes in 5.7 but also because we only have a very, very small subset of concrete5 developers who have either the time or the inclination to make their add-ons compatible with 5.7. I hope I'm wrong but I think concrete5 has been set back to 2008 and will have to re-build their entire eco-system of add-ons which will take years and allow competitors to pass us by. From the look of it, the vast majority of concrete5 developers seem to have built their original add-on as an interesting project but have earned so little net profit from them that they are not interested in doing it all again.
Without a push-button migration path, upgrading is going to be impossible for a huge number of small business owners and as a professional who makes part of my living upgrading c5 websites, it will be years before I can give a reasonably accurate quote on upgrading/rebuilding a site to 5.7. What's going to happen is that each developer like me will cut, hack and shoehorn old add-ons in our own unique way until they work with 5.7 which then makes the host website almost impossible for any future developer to maintain.
Someone please tell me why I should be more optimistic.
Without a push-button migration path, upgrading is going to be impossible for a huge number of small business owners and as a professional who makes part of my living upgrading c5 websites, it will be years before I can give a reasonably accurate quote on upgrading/rebuilding a site to 5.7. What's going to happen is that each developer like me will cut, hack and shoehorn old add-ons in our own unique way until they work with 5.7 which then makes the host website almost impossible for any future developer to maintain.
Someone please tell me why I should be more optimistic.
The first approach is ugly as it would mean we'd make things more complicated, would have to test more and would probably never get rid of those things. That would also mean that your add-ons would be namespace less, nothing something I'm aiming for.
If you want to load namespace add-ons in 5.6, you'd have to rewrite some core classes. I don't think an add-on could do that as classes are loaded internally. I could be wrong though.. I'm not completely against a compatibility layer, but it adds some complexity and would have been tested very thoroughly. I think I'd merge it, but only if a number of people are willing to run a bunch of tests. Or maybe if it was optional..
An add-on would be cool, but again, I doubt it would work unless you've use a bunch of override core by package calls..
Having said this, I've told all of our developers that we're going to use branches. Not something I'm really looking forward to, but with 100+ repositories, it's the only way we can handle 5.7.