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

[Neal Norwitz]

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.

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.

'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.

Bugfix or point releases (eg, 2.x.y) would be made as needed, ~ 3 months.
These releases would still go through the alpha, beta, gamma releases.
This release would be concurrent with the development release.

Since 2.2 is out there, I would suggest putting the bug fix effort
only into it.  There doesn't seem to be enough people to share 
the load for keeping 2.1 in good shape.

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.

The benefits of this scheme is that I think it will appeal to a large
majority of people regardless of whether they are an early-adopters
or not.  The only real drawback is that it will take more time
to keep up the previous released version.  However, I think this
can be minimized by having everyone try to backport their work
if it's a bug fix and have several people handle the patches
for bug fix releases.  I would volunteer to help Michael (or 
whoever rolls 2.2.2), although I don't have enough time to be the One.

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.

Neal