Re: [Chicken-hackers] Re: repository branching

[Alejandro Forero Cuervo]

> >  No one is proposing that new features show up in old eggs.  Old eggs,
> >  once released, will never change.  Even serious bug fixes result in a
> >  new release, not an update to an old egg.  If you don't want upgrades,
> >  do not update your eggs.  Felix did not change this nor are we
> >  proposing that it is changed.
> 
> Sorry, I can't follow.

By "old eggs" I meant "old versions of a given egg".

> By updating eggs in the svn repository regardless of the release
> branch (which, If I understand correctly, you imply when you want to
> keep a single codebase for old and new chicken major versions and
> thus update a new stream-wiki revision in both r2 and r3) the user
> will get your updated code with the new features. Am I
> misunderstanding this here?

Yes.

Ah, so you want to be able to freeze things so that in the future you
can go back exactly to the state the repository was at a given point
in time (eg. when 3.0.0 was released)?

Given that all the old tags are kept in the svn repository, wouldn't
chicken-setup be much better of installing chicken eggs directly from
it, in the case where the last release is not the desired one?  It
would make it possible to specify things such as "install eggs foo,
bar and quux, fetching whichever was the latest version at 2006-11-28"
or "install version 1.1 of egg foo, regardless of how old it is"?
This would be much more flexible than only being able to say "when
3.0.0 was released" or "now".  While this would obviously simplify
post-commit, it would, of course, add a bit (though I think it's just
a bit) of complexity to chicken-setup.  Creating a tag of the
repository in releases/N/ (at a global level) whenever we want to make
it possible in the future to go back to the past seems a bit overkill.

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