[Chicken-users] RFC: stable/unstable release cycles for eggs?

[Alejandro Forero Cuervo]

In drafting my proposal for how chicken-eggs should be structured, it
occurred to me that perhaps we should have some artificial
stable/unstable cycles where every, say 6 or 12 months (or, also, this
could be synchronised with major Chicken releases, whenever they
occur), we "freeze" the code of all eggs and give it a version name
(eg.  'chicken-eggs 1.0', 'chicken-eggs 2.0', etc.).  And, of course,
we let egg authors know in advance when the freeze will take place
(with the goal of allowing them to try to make their eggs be as stable
as possible by then).

In practice, a name such as 'chicken-eggs 1.0' is just a way to refer
to a particular set of versions for each available egg at the time the
name was made (eg. "chicken-eggs 1.0" means something like
"format-modular 1.1, stream-wiki 1.12, srfi-40 1.0, readline 1.91,
...").  Once a given version name has been frozen, it will NEVER be
modified.  In the case of security bugs in egg-foo 1.8, part of
chicken-eggs 1.0, the author will release egg-foo 1.8.1 (even if
egg-foo is already in version 1.12 —because he has been developing it
lots before the security bug was found and because the only difference
between 1.8 and 1.8.1 must be the fix for the security bug—) and a new
minor chicken-eggs version (eg. 1.1) will be made with the updated
list of versions (egg-foo 1.8.1 instead of 1.8).

We will also create a config file that may associate particular
Chicken releases with particular chicken-eggs releases.  When a user
installs an egg:

- If he is using the latest (major) Chicken release, he will, by
  default, get the bleeding edge.

- Older Chicken releases (by major version) will, by default, get eggs
  from one particular chicken-eggs release, as specified in the above
  config file.

Obviously, users will be allowed to override the default (ie.
explicitly specify "bleeding edge" or a particular (major)
chicken-eggs release) if they have reasons to do so.  However, we will
only support the latest N major chicken-eggs releases and for each of
them we will only support the last minor release (eg. once
chicken-eggs 1.1 is released, chicken-eggs 1.0 is not supported
anymore), where N will be determined by the size of the repos and the
space we have in the server and whatnot.

Ignoring any questions about how the layout of the svn repository
would look like (which is not what I want to discuss here; but, in any
case, I think would be very reasonable for most stakeholders), what
would you all think about this?

It should be noted that egg authors can simply ignore this change and
continue to develop eggs as they always have, only supporting the
bleeding edge releases.  As such, I do not think this adds any burden
on them (or, perhaps, the only burden it adds is that if they are only
allowed to release security fixed for old chicken-eggs releases).

Felix, do you think it would address the need that originally prompted
you to change the layout of the chicken-eggs repository?

Thanks.

Alejo.
http://azul.freaks-unidos.net/