Split repos

[iurisilvio]

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?

1. bottle-memcache
2. bottle-redis
3. bottle-sqlite
4. 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.

[iurisilvio]

It is related with #25, the pull request to merge bottle-mongodb here.

[yuripiratello]

:+1:

[defnull]

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]

'm willing to help the bottle, you can count on me!

[defnull]

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]

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]

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]

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]

First of all we need some kind of integration tests. The plugin API is still evolving :)

[avelino]

Yep, 'll look like he's on core plugin API and think of something!