[racket-dev] new release policy

On Aug 11, Shriram Krishnamurthi wrote:
> 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 essentially what happens now, except that it's about two
weeks.  Extending the period makes things (much) more difficult.


> This is sent not only to dev but also to the same low-volume lists
> where releases are announced (announce, edu, ...).

This is a very bad idea.  The announcement list is intended for people
who care only about installing new versions -- things like sysadmins
and 3rd-party packagers.  Bugging them with pre-release announcement
is out of line for such a list.  It's also bad for the users list --
most people don't care to test beta releases, so a call for testing on
releases is made there very occasionally, when there is some major
change to be tested.

In general, I think that there is nothing that can replace the fact
that people that need to test pre-release should be on the dev list.
(Not even a new list just for these announcement, since this will get
to the overly specialized list which will be another thing that nobody
uses.)


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

This is similar to the code freeze period that was used in the past.
It is a pain for everyone since nothing new can get in for a long
time, and it is a pain for the release process and generally is a bad
idea since it adds bureaucratic load in a spot where there is no
manpower to deal with it.

(And BTW, this is unrelated to the open-input-file problem and
keywords that you have encountered in the past -- that "change" was in
much more than a month before the release, and it wasn't actually a
change since it applied to the new `scheme' language rather than the
legacy `mzscheme' one.)

Take this as a -1, multiplied by the factor that corresponds to me
being the person that would need to deal with that load.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!