[Soap-Python] soaplib versioning and community process

[Dieter Maurer]

Burak Arslan wrote at 2010-10-7 23:28 +0300:
>maybe i'm taking things too literally. here's what the lgpl says:
>
>... PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
>KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
>IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>PURPOSE.
>
>so i could even transform soaplib to a library that just outputs random
>breakfast recipes on import, and you can't blame me for what i did,
>because you accepted lgpl by installing soaplib.

You could but, of course, it would make the package useless.

Not using a good release practise, too, makes the package less useful
than it can be.

>so i disagree with all those arguments about why i should care for lazy
>users blindly installing the latest from pypi without running a diff
>with what they already have and expect everything to work smoothly.

In my applications, there are hundreds of packages -- and I am really happy
when the maintainers follow a good release practice (which do not
force me to look at details such as diffs for each upgrade).

I am aware that I have no right to blame them when they do not --
but I choose the packages I use with good release practice
being an important aspect.

I have recently published server side SOAP/WSDL support for Zope, based
on "suds". The current discussion makes me happy that I have chosen
"suds" and not "soaplib" (even though my primary reasoning for the
choice turned out to be wrong: I have thought "suds"
(in contrast to "soaplib") would support SOAP 1.1 and 1.2, but
"suds", too, does not support SOAP 1.2).


>the
>one who installs that software should assume responsibility for his/her
>actions, and can't blame anybody else if an update broke his/her setup.

This is a rather narrow argumentation -- valid for small applications only.

As an example, the package mentioned above has a "suds" dependancy.
To be as usable as possible, it uses a loose dependancy specification
in the form "suds >= ...". Fixing the "suds" version would mean, that
people using the package are very restricted in the "suds" version they
can install.
Of course, the loose specification requires that the "suds" maintainer
does not publish unstable versions on "PyPI"...
If he does, someone installing my package would install something
potentially unworkable...

In addition: most package users would be unable to understand
the true meaning of diffs (or other details). How should they decide
whether a given change would cause problems in their package use?
I think of myself as a good developer. Nevertheless, I do not think
I would be able to determine from "suds" diffs whether or not a given
"suds" version would work with my package.
A good documentation and a good release practice must help me.

Fortunately, the "suds" documentation seems to indicate that
the author has a strong commitment to version compatibility.
A very strong point when I think about its use in my packages.

>that's there, in the contract between you and me, in capital letters, no
>less.

Surely, "suds", too, has such a legal statement in its contract --
as has any open source package I know.

Fortunately, most authors seem to have more ambitions and do
not want to limit themselves to the minimal extent of the "contract".
Otherwise, open source would be useless....

>but,
>
>the soaplib entry in pypi is not my property -- it belongs to everybody.
>i'm just doing a kind of a minor public service by deciding what goes
>in. so i don't think i have the right to ignore what others say about
>how i perform that work.
>
>having seen the reactions to my pypi release policy so far, i will
>delete 2.x from pypi, and won't put it back until there's a reasonable
>agreement on its readiness for a wider audience.
>
>any objections?

I am fine with this offer :-)



--
Dieter