B/C Definition

[Nils Rückmann]

Hi, Thomas and i had a small chat about B/C (See: https://github.com/joomla/joomla-cms/pull/6773).

Maybe it's just me, but i would like to have a definition about what might be a B/C issue and what might be not.

Thomas stated that we only have to take care of the libraries. Is this official ? Is this the right way ?

I don't want to blame Thomas, i just want to be sure, because it may alter the way I (or others) propose changes. I mean if Joomla's B/C promise is only about the libraries, a pull request to remove or heavily alter an extensions would also be legit within minor releases. 

[Michael Babker]

The development strategy (http://developer.joomla.org/cms/development-strategy.html#backward_compatibility) says that only PHP code in the libraries folder is covered by the B/C promise.  So by that text, no, extensions are not covered.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Nils Rückmann]

Thanks Michael. But does the announced strategy also apply in practise ? 

Examples:

1) Removing urls and images from com_content.article / replace it with core_urls core_images

2) Alter com_search in a way which forces the plugins to be modified as well.

3) Remove an entire extension 

Are all those examples legit changes between minor releases ? I think you get my point. I'm just curious where Joomla defines the line.

[Bakual]

1) Not sure what you mean. Regarding core extensions the question usually is if templates would break due to the changes. There is no B/C for the code itself, but for the end result there sure is. For example URLs need to still work, output has to be more or less the same, template overrides still need to work. If a user updates Joomla and suddenly the extensions don't work anymore, it's a fail.

2) com_search uses an API to trigger the plugins. This API has to be kept B/C obviously. How com_search works internally can be changed.

3) We did that already with com_weblinks. The same as 1) applies. Websites are not allowed to break during an update. So removed extensions will have to be left on the system.

Mostly it's common sense when it comes to extensions.

[Nils Rückmann]

1) It's just an example for moving towards UCM (where JTableCorecontent does have "core_images" etc.).

But thanks @Thomas and Michael. It seems like there are less restrictions than i thought. Good to know for future PRs.