We had a good discussion in the dev call today about how to handle cases where functionality needs to be moved from one module to another. Specifically, we were discussing the issue that came up in this pull request: Add Equipment type field to Equipment assets by mstenta · Pull Request #894 · farmOS/farmOS · GitHub
That PR adds a new “Equipment Type” vocabulary and field to Equipment assets. It is essentially adopting the feature that @Fosten implemented in this contrib module: GitHub - Fosten/farm_equipment_asset_extended: An extended farmOS equipment asset.
As a matter of policy, we want to be able to encourage people to experiment with new features in contrib/custom modules, and have a clear pathway to “absorb” those into core (or vice versa: to split features out of core and into contrib modules). There are some technical challenges and considerations to doing this, however, which we discovered in that PR.
So, I thought it would be worth starting a forum topic to discuss solutions to this problem and best practices / policies / recommendations for avoiding it in the future.
In this specific case, the issue arose from the fact that farmOS core wanted to create a new configuration entity (the equipment_type vocabulary), but can not because one already exists with that ID, if you have @Fosten’s farm_equipment_asset_extended module installed. There’s no way for farmOS core to know what contrib modules add, so it’s hard to avoid conflicts like this, but perhaps we can provide some guidance to module devs, as well as internal policies for introducing potentially conflicting functionality, to make issues less likely.
Two ideas to kick off the discussion, which came up on the dev call:
- Should we encourage all contrib module developers to namespace new vocabularies, asset/log/plan types, field names, etc, in order to leave the door open for farmOS core to introduce them itself?
- Advantage: makes “absorbing” the functionality into core easier.
- Disadvantage: adding namespaces to everything means less elegant data model naming in contrib.
- Should we introduce a core policy of not adding new fields/entity types/vocabularies/etc in minor version releases? In other words, no data model changes (including additions!) outside of major releases?
- Advantage: allows contrib module maintainers to use version constraints in their module
*.info.ymlfile to restrict it to specific major versions, and handle upgrade paths when features need to move around between core/contrib more intentionally. - Disadvantage: farmOS core will be much slower to add simple things (like “Equipment type”).
- Advantage: allows contrib module maintainers to use version constraints in their module