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

[Alex Martelli]

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