In #117, @quicksketch wrote that the backdrop = 1.x would be "replacing" core = 8.x. I think I'm following this correctly and replacing only refers to Backdrop's includes/ Modules will be adding backdrop = 1.x in addition to core = 7.x in their .info, right?

I wrote a bit about how the .info file could be used in a responsible fork back when @chx was considering forking...

I even used a response from @quicksketch to an OpenAtrium user to make my case about how frustrated module maintainers get when someone posts an issue in a queue about something that required them to know/understand a version of Drupal that was "off in its own little world".

If I understand this correctly, assuming #3 is resolved w/ function wrappers, that could that make it really easy for maintainers of some modules to add Backdrop support... which is GREAT! But I think it's safe to assume that some module maintainers aren't going to want to support Backdrop no matter how easy it is. In the case of popular modules where the maintainer doesn't add Backdrop support, it seems pretty likely someone else will fork the module to Github or somewhere other than

In anticipation of that, I'd suggest adding support = url (similar to the configure =, but with support for absolute urls) to the .info file and include that support link in the admin/modules UI. I can see a number of module maintainers getting annoyed if they decide not to support for Backdrop in their .info, someone forks the module to Github and makes changes, and issues end up in the original queue on

This wouldn't keep all Backdrop issues out of a "hostile" queue, but if it was included in the initial release and documentation it might get the majority of issues in the right queue.

GitHub Issue #: