Closed chillu closed 6 years ago
@robbieaverill Do you think this is change/major
because a new module would require a new namespace? We could "wrap" those new namespaced blocks as subclasses under their current namespace, which makes it backwards compatible? Not sure how elemental handles subclasses, but we could always blacklist the undesired duplicate classes through YAML config, right?
You could do, but that would probably still involve a DB schema change right?
It might be worth discussing this with @clarkepaul - this block formation was part of the original design
I don't see how this change has any UX implications - it's just moving code from one place to another. Regarding DB schema change, we can set (and keep) table names, right?
Fair enough - I think we should bite the bullet and release a new major version as opposed to leaving shortcut subclasses around - what do you think?
I'm less fussed about major versions of this module, and more around the availability of this in the CWP 2.x release line. However we can make that happen
Cool, in that case let's go new major version sooner rather than later for the sake of reducing tech debt with shortcut classes 😃
Can you get this on the CCers backlog please?
Done:
I've marked this module as deprecated with these suggestions for future, have made 1.0 the default and noted we'll only be accepting patch pull requests from now on against this branch.
The silverstripe/recipe-content-blocks
v2 will include these modules instead along with elemental v3 over v2
We should be setting a good precedent here. By lumping multiple blocks into the same module, we're forcing devs to include more than they might need (or actively work to disable those blocks).
Dynamic Agency has gone the same way, splitting up into individual repos: https://github.com/dynamic?utf8=%E2%9C%93&q=elemental&type=&language=