[Chicken-users] Re: [Chicken-hackers] Re: repository branching

[Alejandro Forero Cuervo]

> 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/