All plugins as their own repositories
Currently there is one big repository for Elgg and all its plugins. There are some new plugins being added (login_as and a new theme). Those new plugins will reside in their own repo. Is this something we will want to do for all our plugins?
Pro:
- Clear seperation of issues
- Potential plugin collaborators (but not core)
- All kinds of fancy composer posibilities (like a per client/install set of core + plugins)
Con:
- We need to move all plugins + related issues to their own repo's (a few days of work)
- Sometimes you need to split PR's
- Need semver for plugin repos
- We loose commit history if we move them to their own repo's
probably more pro's and con's but it was just wondering if this is something Elgg is aiming for
Feedback and Planning
Discussions about the past, present, and future of Elgg and this community site.
- Paweł Sroka@srokap
Paweł Sroka - 0 likes
- that would help a lot with https://github.com/Elgg/Elgg/issues/7721 (see also this experiment: https://github.com/Srokap/elgg_as_dep)
- It would require introducing versioning into all plugins
- basically we first do necessary core changes
- than update plugin and tag new plugin version
- than we bump requirement in the core
- We don't have to loose history, could use git subtree split to keep the history.
- Jeroen Dalsem@jdalsem
Jeroen Dalsem - 0 likes
- Steve Clay@steve_clay
Steve Clay - 0 likes
- IMO the real ROI of this work seems very low for the vast majority of Elgg users, with significant new costs for team members.
- This would seem to introduce significant friction to any change that requires coordination across core/plugin boundaries. I think we do an awful lot of these. Consider #7688 or #5947
- Managing permissions across 35 new repos and convincing team devs to subscribe to notifications on them.
- May lead to even more variance in how plugins are structured (maybe this doesn't matter).
- Steve Clay@steve_clay
Steve Clay - 0 likes
- Evan Winslow@ewinslow
Evan Winslow - 0 likes
- Evan Winslow@ewinslow
Evan Winslow - 0 likes
- Matt Beckett@Beck24
Matt Beckett - 0 likes
- Evan Winslow@ewinslow
Evan Winslow - 0 likes
You must log in to post replies.Quick points from me:
That adds to the plugin development process, but on the other hand we really don't get that much work on the plugins really so it would be a particularly big deal. Could also track plugin versions with something like https://www.versioneye.com/
If plugins also do semver nicely, we only need to bump core plugin inclusion on major release changes, so that is not that often.
Concerns:
FYI I'm not against adding existing 3rd party plugins via composer, as it takes little effort.
I think this would be a net positive move because of the possibility of making elgg and dependencies fully managed by composer.
Managing permissions is not an issue IMO - GitHub organization groups solves this nicely and you are auto subscribed to repos that you get wrote access to, iirc.
I also believe this would be great because this is how literally every other plugin dev does it. One repo per plugin. This incentivizes keeping overhead low for managing plugins. I.e. basically all I want to have to do any more is add the git tag and maybe update translations every once in a while. Even generating the change log feels like overhead. Packagist automatically updates when a new tag is added, why not the community plugins repo and elgg.org? Releasing plugins is such a painfully manual process still and it really shouldn't be.
I also very much like the possibility of adding folks to manage official plugins but not core. Since plugins just aren't getting enough love.
Good points on all sides. Though what is a group of people that would need write access to plugins that don't already have write access to core? We went really permissive with write access to core not long ago and it seems to have worked out pretty well.
Yes, that particular aspect is less of an issue now, for sure. But I think we're a bit more protective of core in general than we are of certain plugins.