[Soap-Python] soaplib versioning and community process (conclusions)

[Burak Arslan]

all,

you might remember the recent heated discussion about how soaplib
releases get handled. i wanted to summarize the conclusions that we came
to, in order not to leave the thread hanging.

1) chris austin from brad's team has full access to the soaplib repo.

2) development will happen in personal forks. the new features will get
merged to the main repo once completed.

brad's idea of *_dev branches are not needed thanks to the code review
features of github.

3) there will be no change in the soaplib versions.

there are disagreements over whether the soaplib-1.0 release is mature
and stable enough for a 1.0 release. however, we all agree that changing
the version numbers of already-released packages would be a very
confusing move. as i did not want to do such a thing without good
reason, we are keeping the version numbers as they are.

4) soaplib-2.0 won't hit pypi until there's reasonable consensus on its
readiness for a wider audience.

5) i have been respecting, and will respect, semantic versioning rules,
outlined at semver.org. this means we keep backwards compatibility on
major versions. (e.g. 2.0.x code will run unmodified on 2.1, but 3.0 may
or may not break some (or all) compatibility with 2.x)

and it will be a more committee-like decision process from now on.

6) on a more personal note, i won't provide compatibility layers between
incompatible versions, and will remind you the relevant parts of the
lgpl if you keep on complaining.

oh but, we will certainly review them for inclusion to the point-oh
releases if a decent contribution comes our way.

it's also false to assume that if so-and-so distro has this-and-that
package in its repo, it must be stable and ready for production use.
(e.g. soaplib-0.8.1 had epic bugs regarding compatibility) always use
the latest package from pypi (with keeping an eye on major versions and
alpha-beta tags) and don't rely solely on what distros offer. and i'm
not saying this to belittle the work those folks do, it's just that they
can never judge the stability of a package better than the package's author.

anybody with anything to add?

yours,
burak