Movatterモバイル変換
[0]ホーム
[Python-Dev] Release Schedules (was Stability & change)
Neal Norwitzneal@metaslash.com
Mon, 08 Apr 2002 21:45:00 -0400
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 oftenI believe we can satisfy both groups--not perfectly, but good enough.This is partly summary and partly suggestion for terminologyand schedule. I propose doing: Release name/typeVersionSchedule -------------------------------- Major releases2.41.5 - 3 years Bugfix releases2.2.1~ 3 months or as needed Development releases2.3a0~ 3 monthsDon'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 fullexecutable, doc, etc. This seems to be the crux of whatmany people want. They want a vibrant changing language. Butthey 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 effortonly 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 wouldbe to satisfy those that want new features or to test compatibilityand are willing to build from source. These should be able to bereleased with very little effort.The benefits of this scheme is that I think it will appeal to a largemajority of people regardless of whether they are an early-adoptersor not. The only real drawback is that it will take more timeto keep up the previous released version. However, I think thiscan be minimized by having everyone try to backport their workif it's a bug fix and have several people handle the patchesfor 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 itreally matter if we call the next release 2.4, 3.0, 2.3-RELEASEor whatever. I personally think the Linux versioning is the mostwell known and a bit more normal for most people over BSD.Neal
[8]ページ先頭