> Please note that from now on you have to chose for which release you > want eggs to be updated: any commits to the old egg directories (as > well as creating new egg directories) will be only available for pre > 3.0.0 chickens. Chickens version 3.0.0rc1 and higher donwload eggs > from a different location, which is fed from commits to the > release/3 repository branch. If you want to maintain eggs for both > releases, you will have to merge manually.
Umm, what's the motivation for this? I think it's a bad idea not only because it makes the size of a checkout of the repository grow greatly with each major release but, more importantly, because it adds complexity which, AFAICS, is not justified. If I now say “stream-ext v1.8”, no one knows if I'm refering to the code in 3/stream-ext/tags/1.8 or to the code in stream-ext/tags/1.8. Now I have to say “stream-ext v1.8 for release 3”. If the goal is to allow us to use different code in our eggs for each Chicken release, it should force us to use different version numbers (so that at least stream-ext v1.8 always refers to the same particular code, even if it has to live in multiple locations, which maintainers will need to manually keep in sync). If I have egg-version 1.7 for Chicken 2 and egg-version 1.8 for release 3 and then I need to make a release of my egg that will only work for Chicken 2, what version number should I use? Should I use 1.8, making “egg-foo v1.8” refer to two different chunks of codes or should I use 1.9, making people running v1.8 feel that they need to update? I can think of several alternatives: - Trying to standarize on version numbers beginning with the number of the release (eg. stream-ext/tags/3.1.8 vs stream-ext/tags/2.1.8). For eggs that need them, branches for older releases would be kept in branches, as in stream-ext/branches/2/. - Embedding the number of major release in the name of the egg, to end up with stream-ext-2 and stream-ext-3. This is probably the simplest solution. - Extending the .meta files to specify which releases are supported by each version of an egg would probably have been even better (so in the meta files you specify the releases supported and the post-commit code figures out which is the latest supported egg release for each Chicken release). What percentage of the eggs do we really expect to require different code for each Chicken release? I would imagine that the percentage is very small, but I don't really know... As a maintainer of eggs, I find the idea of having to keep separate directories for each egg for each release that I want to support unbearable. If I maintain 15 eggs, I will have to maintain 45 different directories the next time a major release comes along. To make a release of a new version of my code, I now have to sync the two dirs and make two releases, separatelly. And worse, since I have 2 (and eventually more) trunks, chances are that they will diverge and I'll end up having to waste time merging them and figuring out what changed in one but failed to make it to the other. This change is not only inconsistent with the way most svn repositories tend to be used and redundant with the standard practices of /tags and /branches, but it puts a burden on the maintainers, when I think we ought to be striving for the opposite goal. Maintainers are short on time; we shouldn't waste it by forcing them to spend some of this sync'ing multiple directories and increasing the complexity associated with their eggs. Alejo, a bit frustrated by this change. http://azul.freaks-unidos.net/ _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
