localgovdrupal
Proposal: localgov_bleeding_edge
I've been involved in a few discussions recently about what features should be rolled out to existing sites, and where to put the code that enables new features / modifies existing config, etc.
There's definitely sites out there that would like to have the latest features automatically installed. There's also some out there that would not.
I'm thinking we let sites choose, by using a new module in its own project, which could be called localgov_bleeding_edge localgov_up_to_date, localgov_automatic_updates, etc. Please feel free to suggest your favourite name in the comments, but I'll stick to localgov_bleeding_edge for the moment.
We install localgov_bleeding_edge with the project, and enable it by default. In the future, when we add new features to localgov, we add their dependencies to:
- The project, so they're added to new installs.
- localgov_bleeding_edge, so they're added to existing installs.
We add config for new features to:
- The project's install config, for new sites.
- localgov_bleeding_edge's update hooks, for existing sites.
New sites will get automatic updates by default, but if you don't want your site to be automatically updated, you can remove localgov_bleeding_edge and it won't be. But you can still get an idea of what's been added since your site was created by looking through the release history of localgov_bleeding_edge.
Existing sites can opt into automatic updates by adding localgov_bleeding_edge to their build.
This sounds like a really good idea, though I don't like the name "Bleeding edge". It sounds like we are asking people to sign up to be beta tests on their production sites.
I'd be surprised if we collectively decided to call it that TBH. What name would you suggest?
This approach sounds like it has a lot of merit. I wonder how we can get input from a varity of councils on this?
I like the ronseal approach to naming (though ironically the name ronseal means nothing) so localgov_automatic_updates makes sense to me.
I assume then that anyone building a new LGD module would need to update this module too?
I've added this to governance, @rupertj would you like to be involved in Tech Governance moving forwards? There is a 1 hour meeting once a month.
I assume then that anyone building a new LGD module would need to update this module too?
Anyone creating a new module that's part of a default new install could use localgov_automatic_updates (or whatever it's called) to enable that module on existing sites, so yes. But any updates to their new module should be handled by that module itself.
Hi folks.
"where to put the code that enables new features / modifies existing config, etc." <- this sounds like a case for recipes. They can package and install dependencies and modify config settings through config actions. Has the recipes system been considered?
I don't think recipes help here (unless my understanding of recipes is wrong). Once a recipe is applied to a site, that's it. There's no ability to update an existing recipe or apply new ones based on it.
So even when we get to the point where the LGD profile is built from recipes, we'll still need a way to optionally apply new recipes to existing sites, or make changes to config previously added from recipes.
Just thinking how this might work in practice.
For example: We decide to change how a field is displayed on the page and in a view. At the moment we don't add an update hook for these sorts of changes as we don't know if people have already made changes to the field displays. Is the proposal that this module would contain an update hook for this so existing sites that want to track changes as close as possible will get this change?
I do think allowing sites to get the latest changes is a good idea. There will be some extra work in writing and testing the update hooks and the hooks themselves would need to make plenty of checks to ensure the relevant module is enabled and the config exists.
I do wonder if putting all of this in a single module is a good idea. We would need to ensure releases happen in two places and testing will be a little more involved.
An alternative approach could be to add the update hooks to the module where the config changes are being made and set a config item (e.g. localgov_automatic_updates) that is checked in the update hook and the changes only applied when this is true.
Recipes can be re-applied or new recipes applied to modify, update, overwrite, add configuration. The difficulty will be trying to apply configuration to a site with unknown configuration state (even if opted in). Not sure what powers update hooks have to check the state of configuration before applying but recipes have some capabilities to help orchestrate it. It's early days for recipes of course.
New information: I jumped the gun. Some of the things necessary for the above comment to be true have not made it into core yet. It should read instead "Recipes will hopefully be able to..."
I'm starting to think that instead of implementing this in a separate module, a better way to do it would be via the profile. So if you want the new features automatically installed, you use the profile. If you don't, don't use the profile.
There's a couple of changes that we'd need to make to enable this:
- Remove existing features from the profile and put them in separate modules so people who don't use the profile can continue to use the features.
- Adopt a policy of "No new features in the profile", but new features can be as dependencies of the profile. Then existing sites can opt into features they want by adding those modules.
I'm starting to think that instead of implementing this in a separate module, a better way to do it would be via the profile. So if you want the new features automatically installed, you use the profile. If you don't, don't use the profile.
What would happen to existing sites that are already using the profile? The vast majority of LGD sites have been installed with the profile and we don't want to to suddenly start applying updates to their sites. I'm also not sure we want to ask everyone to uninstall the profile if they don't want to start receiving updates. For existing sites this should be an opt-in feature rather than opt-out.
I still think we would need a setting to turn this feature on and which update hooks will need to check before applying config changes.
We should probably have a meeting about this to figure out the what/why/how of what we want. I've a feeling we have a few very different views about whether we should apply updates to existing sites (I think we should) and how we should apply them (opt-in, opt-in for a while but eventually you must have it (like a new design for Gmail for example), forced, etc).
We can post the summary of the meeting here as a comment.