[Soap-Python] soaplib versioning and community process

[Burak Arslan]

hi,

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.

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. 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.
that's there, in the contract between you and me, in capital letters, no
less.

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?

best regards,
burak



On 10/07/10 21:21, Dieter Maurer wrote:
> Burak Arslan wrote at 2010-10-7 14:27 +0300:
>> On 10/07/10 13:40, Dieter Maurer wrote:
>>> Burak Arslan wrote at 2010-10-7 11:27 +0300:
>>>> ...
>>>> so, 2.0 is alpha. i can't make it clearer that it's not ready for
>>>> production yet. if you don't want to run my half-baked alpha software, do
>>>> this:
>>> It may seem surprising, that 2.0 is started before 1.0 is finally released.
>>>
>> hello dieter,
>>
>> soaplib development never stopped. i just created a branch before
>> starting another overhaul, so that those who need a stable version
>> sooner rather than later have something to work with. did you see the
>> diff stat between 1_0 and master?
> I am no "soaplib" user -- and read "soap at python.org" out of a general
> interest in webservice support by Python.
>
> My comments, therefore, are more general, not primarily related to
> "soaplib".
>
> "PyPI", per default, shows only the latest version of
> a package. Therefore, it is probably that a novice user of a package
> will see and use this latest version, even if it is not yet stable.
> The maintainer can change this default behaviour. If he does, it
> is less critical to register unstable versions (provided a stable version
> is listed on "PyPI").
>
> Users of a package likely want to profit from bug fixes. Therefore,
> dependency specifications in the form ">= <some working version>" are
> quite frequent. They often forget that newer versions may be unstable
> or even completely incompatible. Those users will be happy, when
> only stable (and if possible compatible) versions are only registered with
> "PyPI".
>
>> ...
>> it touches almost the whole code base! the 1_0 branch did see some
>> real-world testing, and i did not want to throw that all away. i
>> explained why i can't stabilize soaplib-1.0 in another message.
> I do not think that the original poster argues against you starting
> work on a new "soaplib" generation. Due to peculiarities of "PyPI",
> he probably has only reservations with respect to the "PyPI" registration.
> Such a registration is probably only advicable when a large audience, far
> beyond the developers and "pilot" users, might be interested in the version.
> This strongly encourages only to register stable versions.
>
>> i have to work at my own pace. that's the best i can do for everybody
>> else without distorting my own schedule.
>>
>>> This indicates a great deal of instability in the development process
>>> (major versions are often associated with incompatible changes) --
>>> not a good sign for the adoption of a package...
>> i disagree. i think fast iteration is a positive sign.
> I am building large Zope applications which include hundreds of packages.
> Therefore, I am happy when these packages have as few incompatible
> changes (usually indicated by a change in the major version number)
> as possible.
>
> I have learned (by bad experience) that I must not trust package maintainers
> that they use "PyPI" in a "general audience friendly" way.
> I "fix" now the version to be included for each included package.
>
> Nevertheless, I try to convince package maintainers to use
> "PyPI" primarily to target the "general audience" and not "abuse" it
> for "development purposes". Developers can easily access unstable code
> from the code repositories and do not need "PyPI".
>
>> ...
>> those complaints belong to the setuptools issue tracker. you should know
>> the limitations of your tools and take better care not to break your
>> production.
> I know them. But, you, too, are using "PyPI" and probably should
> consider its typical use to avoid frustration with its other users...
>
>
>
> --
> Dieter