On Thu, Feb 21, 2008 at 9:13 PM, Alejandro Forero Cuervo <[EMAIL PROTECTED]> wrote: > > Umm, what's the motivation for this?
To keep egg sources for released but old versions, with the option of maintaining them. It's quite frustrating (as all of us know), that if I reinstall some eggs (say on a new machine), and those eggs use features that are only supported in newer chickens. > > 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. The repository is already too big to checkout completely (unless you really want or have to). The complexity is IMHO acceptable. There will be some simplification once I have moved the toplevel eggs into a release/2 branch. > > 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? The old tags for older releases are indeed unneccessary (but can be kept for reference). To release an egg for an older version, merge your changes into the appropriate release branch. Old eggs should only be modified for critical bugs (probably on request). The current official chicken version designates the branch you should be working on. > - 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/. We already have differing versioning schemes and we should not start changing everything. > > - 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. No. > > - 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. You should not release for multiple chicken major versions. Release for the current. Only to fix critical bugs should eggs for older releases be modified. > > 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. > Sorry, I may sound somewhat stubborn on this, but the whole machinery to automatically upload eggs on changes is already quite complicated and in place and working and I'm not going to change it (only extend). While I admit that the current layout is a bit confusing, I don't think the complexity is "overwhelming": just don't worry about older releases. But we still have the possibility to maintain eggs for old releases in a relatively simple manner, and this is crucial. Repo checkout size shouldn't be a showstopper. Just checkout what you need or use svn externals. cheers, felix _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
