[racket-dev] new release policy

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