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