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/ _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
