Repository navigation
Split repos #24
Description
This bottle-extras has several plugins and it is a bit confuse to end users to understand where to find these plugins, also it is difficult to organize github issues, handle repository permissions, etc.
E.g. we have a plugin bottle-memcache but we don't have a repository bottle-memcache (it is an SEO problem).
What you guys think about split these plugins in several repositories under bottlepy organization?
- bottle-memcache
- bottle-redis
- bottle-sqlite
- bottle-werkzeug
This way, bottle-extras will have only dependencies to these projects.
I'm asking that because https://github.com/fdouetteau/bottle-mongodb-plugin is abandoned for two years and @avelino want to fork it and put it under bottlepy org. It is an important plugin to bottle environment.
I want to confirm if the way to merge bottle-mongodb is to just pull it to bottle-extras or if split repos is a better option. Only one repository don't scale well for different projects.
Of course, we need @defnull agreement to make this change.
Activity
iurisilvio commentedon Mar 11, 2014
It is related with #25, the pull request to merge bottle-mongodb here.
yuripiratello commentedon Mar 11, 2014
👍
defnull commentedon Mar 11, 2014
The split is done. We can use this repository for meta-stuff (documentation and tools) and the bottle-extras meta-package. We should speak about a team/push/release strategy, too. Currently I am the only one that can release to PyPi.
avelino commentedon Mar 11, 2014
'm willing to help the bottle, you can count on me!
defnull commentedon Mar 11, 2014
Added @avelino and all the bottle-* repositories to the extras-team. We should now fix/discuss the remaining issues that are still in this repository and perhaps trigger some releases?
avelino commentedon Mar 11, 2014
thanks!
@defnull added you in pypi bottle-mongo as Maintainer!
https://pypi.python.org/pypi/bottle-mongo
How is the flow of the bottle (core) release?
defnull commentedon Mar 11, 2014
There is no fixed schedule. The only thing I really try to guarantee is backwards compatibility for at least one minor release in the core framework.
For the plugins I am open for suggestions and more than willing to step back and give control to the community.
avelino commentedon Mar 11, 2014
We can keep the plugins generating sub-version, example:
0.12.x:
0.12 = bottle version
x = plugin version
first release: 0.12.1
Case has little update generates a sub-version (0.12.1.1, 0.12.1.2, 0.12.1.3)
If I have a major update creates a new version of the plugin (0.12.2)
When generate release the bottle 0.14, start new branch in plugins to 0.14.1 ...
This makes it easy to manage the evolution!
defnull commentedon Mar 11, 2014
First of all we need some kind of integration tests. The plugin API is still evolving :)
avelino commentedon Mar 11, 2014
Yep, 'll look like he's on core plugin API and think of something!