Dag Sverre Seljebotn wrote:
> Stefan Behnel wrote:
>> I'm still for moving Cython to the stdlib one day, but I would prefer a
>> somewhat closer "one day". What do the others think?
>>
> The only concern I have is that of release cycles. I.e. would it be
> possible to live within the Python repositories etc., but still do our
> own independent releases? (And when a new version of Python is released,
> and Cython with it, simply release the "cython" branch, i.e. latest
> stable with critical bugfixes). If so, then there's no problem.

That is a concern I have, too. As Martin noted, the main release would
have to happen in the stdlib, which means: adapt to the Python release
cycle. Currently, that's one major release every 1-2 years and a minor
release about every 6-10 months. I doubt that users would honour such a
slowdown in the current state, but I'm sure that we will think different
about this once we reach a freezable language state.

We'll also have to check how other projects handle this. Last time I
asked, I was told that ElementTree was an "externally maintained project
in the stdlib", whatever that means. If we can adopt a release scheme as
you indicated above, i.e. stabilize the language, have a stable release
included, and then keep releasing improvements and optimisations
separately (e.g. in our own hg repo) before they get included in the next
Python release - that sounds acceptable to me.

Language extensions would then still have to wait for a major Python
release, IMHO, but users could benefit from other improvements earlier if
they feel they really need to. But we will have to take care which
improvements go into which Python minor release, and which should wait for
a major release. Older Python branches usually only receive bug fixes, but
new minor releases can well receive general improvements for a while.

Stefan

_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to