[Python-Dev] Release Schedules (was Stability & change) (original) (raw)

Alex Martelli aleax@aleax.it
Tue, 9 Apr 2002 09:10:13 +0200

On Tuesday 09 April 2002 03:45, Neal Norwitz wrote:

There seem to be two groups:

1) Early adopters: release early, release often; more features the better 2) The masses: easy does it, don't break anything, don't release so often I believe we can satisfy both groups--not perfectly, but good enough.

I think this identifies the issues very precisely and proposes a good solution strategy.

This is partly summary and partly suggestion for terminology and schedule. I propose doing: Release name/type Version Schedule ----------------- ------- -------- Major releases 2.4 1.5 - 3 years Bugfix releases 2.2.1 ~ 3 months or as needed Development releases 2.3a0 ~ 3 months Don't get hung up on the version numbers, it doesn't matter. If we agree on the concept, we can name it later.

I fully agree on your concepts. I would suggest some renaming, for clearer/more incisive communication, but you're right, let's not get hang up on that: the substance of your proposal is excellent.

'Major' releases (roughly corresponding to Linux kernel even releases) would occur every ~ 18-36 months. These releases would be full executable, doc, etc. This seems to be the crux of what many people want. They want a vibrant changing language. But they don't want to have to deal with that change. They want longer cycles. We are talking about users of the language, not hard-core developers. These releases would still go through the alpha, beta, gamma releases. The last development release in a cycle would become the first alpha.

Perfect.

Development releases, which are source only, could be released approximately every 3 months. These are basically alpha releases. They roughly correspond to Linux kernel odd releases. This would be to satisfy those that want new features or to test compatibility and are willing to build from source. These should be able to be released with very little effort.

Not sure about the source-only part -- maybe there's some hacker wannabe on some Windows box out there that can't afford to buy VC++6. But I could volunteer to remedy that by compiling and making the win32 binaries available (not an installer: I wouldn't know how to write that, so this would have to be arranged) -- so it's not a killer.

I don't think the numbering/labeling scheme is important. Does it really matter if we call the next release 2.4, 3.0, 2.3-RELEASE or whatever. I personally think the Linux versioning is the most well known and a bit more normal for most people over BSD.

OK. I opine there's a little bit of importance in such "naming", but not all that much -- the substance matters more, and I love the substance of your proposal.

Alex