[Soap-Python] recent pushes to jkp/soaplib

[Brad Allen]

On Wed, Jun 9, 2010 at 6:59 AM, Burak Arslan <burak.arslan at arskom.com.tr> wrote:

> I'll push my version of soaplib soon. It breaks api compatibility with
> existing soaplib, in an effort to be compatible with sqlalchemy's
> declarative; so that one will be able to return table objects without
> any duplication of effort. It is experimental yet compact and seems to
> get the basics right. I'm interested in feedback and patches.

I'm wondering if there is any reason this should not be handled as a
branch instead of a fork. Right now there is only a master branch of
soaplib, but one of the big benefits of using Git is the convenience
of working with branches.

I'd like to suggest we consider the master branch to be a release
branch, and only merge changes into master when it's time for a new
release.

The mainline of work toward the current release could happen in a
branch called 'development'.

If we need to maintain older releases, we could put those in
maintenance branches named after major+minor version numbers, like
'maint_0.8'. Fixes to old releases could be put in release branches
named like 'release_0.8'.

Collectively release and development branches (for both current and
maintenance) could be termed "integration branches". The goal would be
to eventually get all the integration branches running on a continuous
integration server, and set an expectation that nobody should push to
those integration branches until all tests are passing.

However, we can also have some branches which are not considered
integration branches. For example, specific enhancements or bugfixes
could go into "topic branches" named based on the nature of the
change. These kinds of branches would fall under scrutiny for review
before getting merged into an integration branch. Also, topic branches
might be prefixed with the name or initials of the developer, to make
it clear who is responsible for that branch.

We've just started following this approach at my day job, and to me it
makes a lot of sense. It's the kind of thing that was very awkward to
manage under Svn but Git naturally encourages.