Am 15.11.2011 17:55, schrieb Frank Lanitz:
We will have one master branch where all changes intended for releasing are going in. Features and new plugins are going to be developed inside branches (more late onto this topic) and once they are in a suitable status, they are getting merged into master branch. Release are generated from master branch and are getting marked with a tag. If there is any need for some minor release as we had e.g. with 0.21.1 there will be a release branch that will include all patches going in. If they are also needed to get applied on master, we can cherry-pick them or find some other way of merging them back.
I like this proposal. Requiring pull requests will also formally mean "get your plugin in shape" before release. I'd like to extend this to the point that if a plugin is not ready (due to bad code, inactive maintainer, or otherwise) the snapshot from the previous release will be taken as to not lose functionality (this is in most cases automatic, since the merge didn't happen). I strongly advice against delaying releases for individual plugins.
However, there's one problem that isn't addressed, and I'm not sure it can be technically since it's more a cultural problem: There's IMO too little collaboration on plugins. It's kind of "each plugin to its maintainer", with little to no collaborative effort to form the best and greatest plugins. It feels like the source is available but not really open. OTOH perhaps my perception is just wrong, and this cannot be fixed by technical measures anyway.
Regarding the ideas with separate repos/submodules: This basically breaks what the initial idea of geany-plugins was. To share infrastructure, build system and translations. The "combined release" idea came actually some time after that.
If the repos are separate and only merged for release, then they can just as well be separate entirely. So I disagree with that.They should be one repo, since they share a common code base via the translation and infrastructure.
Am 16.11.2011 07:12, schrieb Lex Trotman:
Although I am not a plugin developer I have a couple of suggestions based on the following needs:
- Individual plugin maintainers shouldn't care about all the other
plugins in the combined release
Not caring about other plugins is ok, but that doesn't mean his clone/checkout must not have other plugins.
- Users getting the combined release to build should get everything
in one command
This is status quo, and should be kept, yes.
- The combined release maintainers still need to be able to make
changes to each plugin in case of urgent bugfix and temporarily or permanently missing individual plugin maintainer.
I agree.
- Not all plugins are in the combined release, due to quality,
timing, or maintainer availability issues. But users rely on plugins so it is bad to remove their availability.
Covered by my suggestion to simply re-use the previous release.
Best regards.