Hi, wärt ihr so nett und tragt bitte meine E-Mail Adresse aus den Verteiler aus?
Danke! Lg Stefan Hosemann Von: [email protected] [mailto:[email protected]] Im Auftrag von Alexander Kludt Gesendet: Montag, 26. Jänner 2015 17:11 An: [email protected] Betreff: Re: [oxid-dev-general] Compatiblity best practises Hey there, we are using a combination of a wrapper for the framework classes - means we do not use oxRegistry::get or oxConfig::getInstance anymore. We are shipping our own custom core classes that go to the core folder directly and use them. As an addition we are using ANT Build files to move the files to their correct folders, encode them and put the license management into them. The ANT Script also zips all of them using the correct naming depending on the shop version.All of this is done through a Jenkins server that will also publish all of this to our webshop. So the Setup is: Custom Core Wrapper SVN ANT Ioncube Jenkins To answer your question, it's Multiple Packages built from one source code tree. best alex [cid:[email protected]] Alex Schwarz<mailto:[email protected]> Montag, 26. Januar 2015 16:58 Hello my developer friends, what are your best practises to ensure compatiblity for older OXID versions? It is common to have separate branches for 4.7.x, 4.8.x, 4.9.x and so on, or do you try to have one code base? For example I use params in language strings introduced in 4.8 and they do not work in 4.7. Building an if-else construct in smarty templates querying the OXID version seems to be a bad practice. Same for the oxConfig/oxRegistry changes, here I could go with a function_exists/class_exists; just interesting how you think about that. A: One package B: Multiple packages Best regards
_______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
