Re: [Chicken-hackers] Re: repository branching

[felix winkelmann]

On Tue, Feb 26, 2008 at 9:19 AM, Alejandro Forero Cuervo
<address@hidden> wrote:
> > >  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".
>

Yeah, I understood that part. Perhaps we should come up with
a proper terminology before we continue...

Do you mean with "old eggs, once released, will never change" that
we keep archives of .egg files? Or what do you mean, specifically?

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

(assuming you mean "yes: you are misunderstanding")

>
>  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)?

I merely want historical chicken versions (as much as possible) to
work, including eggs that were released at that point. We have now
started a policy of only bumping the major version of chicken (>>3<<.0.0)
for backward-incompatible changes (yes, this should have been done
much earlier). A backward-incompatible change (removing functionality,
significantly changing existing functionality to make it semantically or
syntactically incompatible with existing code) should not influence
already released eggs for older chicken versions. It should also
be possible to still fix things (using standard repository operations, i.e.
being simple) in eggs for older chicken releases. I firmly believe that
it is not possible to safely maintain a common codebase that works
over a range of chicken major versions.

So the only approach I can deem practical is to be conservative:
freeze the set of available eggs for historical chicken versions,
while stiill having the option of maintaining them, should the need
arise.

I understand that for those who think that the differences between
major chicken versions are negligible and easy to manage by
metaprogramming or clean coding consider the current repo
layout inconvenient. But by actually following the current
policy, nothing is lost. If a user wants bleeding edge features, the
requirement to upgrade to the current major release of chicken
is IMHO acceptable (he wants bleeding edge features, doesn't she?).
By simply ignoring release/2, you still have the same ease of
working the the repo as before the branching.

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

If you imply to access particular versions of eggs with svn, then I must
say that I consider this unacceptable. Chicken-setup
may not depend on any particular VCS client. tar and gzip is bad enough.

Another point is that chicken-setup is already way too complex.

I hope this message doesn't sound to dogmatic. I'm really concerned
about this subject as it has the most influence on how we will
do out daily work and maintenance with the chicken stuff, how
users will perceive and accept it and how contributors enjoy to
contribute. Just give me kick when I start getting nasty...


cheers,
felix