[Soap-Python] soaplib versioning and community process

[Dieter Maurer]

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