[Soap-Python] soaplib versioning and community process

[Burak Arslan]

 hello,

On 10/07/10 18:56, Brad Allen wrote:
> I would like to suggest that for soaplib, we follow the Semantic
> Versioning rules laid out at semver.org.
>

we already do, no? i will (and do) increment major version every time i
break backwards compatibility.

> The fast iteration is great, Burak. However I would prefer it happen
> in a topic branch, and should undergo some community code review
> before merging into a branch destined for release. I can volunteer my
> co-worker Chris Austin to help with the review process, and I hope
> others in the community will volunteer to participate in the code
> review process. 

that's overkill for a tiny project like soaplib. i'm not going to waste
time juggling all that.

we have the master branch, stable branches and tags. we'll iteratively
review changes to master, addressing concerns raised in reviews in later
commits. once the master is mature enough, it's copied to a new stable
branch, or cherry-pick'd to an existing one. once there are enough
changes that went into stable branches, we tag it and release.
 

> Brad wrote:
>> Now that 1.0 and 2.0 have been released on PyPI, does that mean we
>> can't go back in time and do-over?
> Burak responded:
>> sorry, what do you mean? i'm not familiar with this expression.
> I'd like to re-version both the 1.x and the 2.x versions to be part of
> the 0.9 series, in keeping with semantic versioning rules and
> community expectations about the meanings of major release versions.
>
> 1.0 could become 0.9.4  (or maybe should not even have a release
> version, just a branch name)
> 2.0 could become 0.9.5  (this branch would be the basis for heading toward 1.0)
>
> PyPI should be pointed to the latest stable release. The 0.9.5 branch
> would ultimately evolve toward becoming 1.0.
>
> This might seem like a disruptive move and potentially create
> confusion, but frankly I don't think soaplib is widely used yet. A
> clear explanation on the PyPI page would likely prevent confusion, and
> people who want to try out unstable versions could be directed to
> Github.
>

i'll need more than your frank belief about soaplib's usage to base such
a disruptive and confusing move on. also, my frank belief doesn't agree.
e.g. there are already django integration recipes for soaplib 1.0.



> Burak wrote:
>> so anybody who wants to see a stable 1.0 release should start fixing
>> those tests and send pull requests for the 1_0 branch my way. otherwise,
>> i'm afraid soaplib 1.0 will be stuck in beta-limbo forever.
> I don't see any benefit to continuing along that branch;

neither do i. but, there may be others who just need a soap server and
are happy with what soaplib-1.0 has to offer.

>  does anyone
> else? Is anybody using it at all? The approach taken in the 2.0 branch
> addresses important separation of concerns.

thanks!

> I would like to suggest we define particular branches to be
> "integration" branches, meaning that those are collaborative branches
> destined for release. Those branches should go under continuous
> integration, and topic branches should be reviewed before merging into
> integration branches.
>
> We should also adopt a policy of never merging to integration branches
> unless tests are passing. This is not an onerous requirement; any
> non-integration branches (usually called "topic branches") can be used
> for work which involves temporarily breaking tests.
>
> I am volunteering some resources to support this kind of process.
> Where I work, soaplib is a critical dependency, and we'd like to
> foster a community process leading toward greater robustness. By that
> I mean, we want it to have a comprehensive feature set, elegant
> testable design, strong standards adherence, and good interoperability
> with other widely used SOAP implementations (.NET and Java).
>
> We have several developers who can contribute. Chris Austin in
> particular has recently started working on soaplib; he started with
> updating the Sphinx documentation for the 1.0 beta, and since then has
> been working on fixes to tests. He can help out with further
> enhancements to soaplib going forward.
>
> We're also thinking about creating soaplib jobs on our Hudson
> continuous integration servers to run tests on specified branches of
> soaplib whenever new codes appear. We can set up those jobs to email
> the community if tests fail under Windows or Linux (though we don't
> yet have any tests specific to .NET or Java right now).
>
> If the community is in favor of this line of thinking, we can put
> together a more detailed proposal of how the integration branches
> could be organized, how the release process can be managed, etc.

just send the .net and java interop tests my way when you finish them.

best,
burak