[Python-Dev] Release Schedules (was Stability & change)
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
> 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.
> 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.