chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] Re: repository branching


From: Mario Domenech Goulart
Subject: Re: [Chicken-hackers] Re: repository branching
Date: 26 Feb 2008 12:19:12 -0300
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Hi folks,

On Tue, 26 Feb 2008 08:55:22 +0100 "felix winkelmann" <address@hidden> wrote:

> On Tue, Feb 26, 2008 at 1:17 AM, Alejandro Forero Cuervo
> <address@hidden> wrote:
> >
> >  Ok, actually it can be argued that the releases/N change does make it
> >  possible for new features to start showing up in old eggs, given that
> >  you can one day release stream-wiki 1.12 in
> >  releases/2/stream-wiki/tags/1.12 and then, one month later, release
> >  stream-wiki 1.12 in releases/3/stream-wiki/tags/1.12, with a
> >  completely different codebase (or the same thing swapping the /3/ and
> >  the /2/).
> >
> >  The fact that the new system supports this is only one of the multiple
> >  reasons why I think this change breaks chicken-eggs enough that I'm
> >  right now seriously looking for other systems to move my code from
> >  chicken-eggs into (with one option being simply just copying it all
> >  into Svnwiki).
> 
> Sorry, I don't understand this at all. Do you agree that someone who
> has to maintain a system with an old chicken-version doesn't want to
> get bleeding edge features in eggs when reinstalling a set of extensions?
> Being able to run chicken-setup without the need to do personal
> backups of particular egg versions is something that I consider
> really useful (I do it myself - since chicken-setup handles the
> dependencies for me, I usually install directly from the egg server,
> and not from local backups).

What do you think about having a `global' directory under `releases',
so developers who don't want to maintain per chicken release egg
branch (or don't want old chicken versions to use feature crippled
eggs) can keep their code?  We'd have something like this:

  chicken-eggs/release/2
  chicken-eggs/release/3
  chicken-eggs/release/global

The ones who want to maintain only one branch, chicken release
independent, for their eggs, put the code under `global' (or a better
name).  These eggs should be published to all the release repository
locations (i.e., http://call/cc.org/eggs and
http://call/cc.org/eggs/3, currently).

The ones who want to keep eggs according to chicken major version
should user release/<major-version>.  In this case, the publication
should be done as it is nowadays.

I'm proposing this because I feel the main discussion is about
problems for developers, not for users, as long as eggs work.

Developers who adopt the `global' structure should be very careful
regarding to dependencies versions, since they may come from any egg
release branch.


Best wishes,
Mario




reply via email to

[Prev in Thread] Current Thread [Next in Thread]