This is a step in the right direction but, I think, not quite enough. Frankly, it does not touch my biggest concern of lack of stability. It will actually make things worse, because >time between releases => >difference between releases, so things will break even more.
As an alternative, I propose two things: 1. Giving people a "release checkpoint" against which they can test their libraries/support code before the release becomes final, and giving them a reasonable amount of time in which to do this. 2. Setting a clear policy on changes. 1. Here's what I have in mind for times: eg: July 1: Here is version 5.2pre. You have a month in which to test your libraries, courseware, etc. 5.2pre will become 5.2 unless this month finds egregious problems, so if your updated system works against 5.2pre, it will most very almost certainly work under 5.2. This is sent not only to dev but also to the same low-volume lists where releases are announced (announce, edu, ...). August 1: Here is 5.2, which is the same as 5.2pre (modulo critical changes). If the change from 5.2pre to 5.2 is extreme, consider putting out 5.2pre2 and waiting one more week. This happens at most once. 2. Furthermore, I suggest this policy: Any API change that was not put into public git at least 1 month before pre is considered to be a bug. To take a random example, if open-input-file changes its semantics to no longer take strings a week before 5.2pre, no matter how well-motivated the change, this is considered a bug and must roll back. It is welcome in 5.3. This makes it possible to send one more announcement, a month before pre, warning of upcoming changes. Developers can decide how much these affect them, and therefore how much time they need to budget and when to do so (eg, go with nightly build right away, or wait a month and use the stable pre). I claim these balance the need to accommodate innovation with the provision of some combination of stability and warning about instability. It sends a message that we welcome users with more passion than time. At the same time, because of the ready availability of nightly builds, someone who wants a cutting-edge innovation (a developer or a researcher) can still access it. Shriram _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
