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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4