[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] Re: repository branching
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] Re: repository branching |
Date: |
Tue, 26 Feb 2008 13:17:54 +0100 |
User-agent: |
Mutt/1.4.2.3i |
On Tue, Feb 26, 2008 at 11:55:42AM +0100, felix winkelmann wrote:
> On Tue, Feb 26, 2008 at 11:28 AM, Peter Bex <address@hidden> wrote:
>
> > This means you need an egg file for every egg release. Chicken-setup will
> > fetch the latest egg it can find *with compatibility for your chicken
> > version*,
> > as stated by the meta file. It would be an error if bar turns out not to
> > exist for all the same chicken versions foo is said to support.
> > (salmonella
> > could check this, BTW)
>
> Hm... So you keep .egg files around? I dunno... I don't like this. There
> should be one egg for each major release that represents the official
> working version for that (chicken) release. It would probably be good
> to have a "development" egg that represents the development version.
What about my example from Rails? If one develops an app with one egg, and
that egg gets a backwards-incompatible update to itself, while the Chicken
release remains the same, you must have a way to stick that old egg on your
brand new server you want to deploy the old app on.
> What do you mean with "as stated in the metafile"? What kind of information
> (an example would be good) would you like to specify there?
* The chicken versions it is known to work with
* The dependencies and their exact version
If a dependency gets a new release, you can only get that new dependency
working with the egg if the egg gets an update in its meta file and a new
release is made of the egg.
> How would you
> want to state with what eggs are compatible to each other, for a given
> major release of a "base" chicken?
As described above.
> > I don't see how this is much harder than what we have now.
> >
>
> I think we should go into more detail if we want to avoid to state repeatedly
> that we don't understand each other, which should be clear enough by now.
Sure.
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
pgpilpmz9OeJh.pgp
Description: PGP signature
- Re: [Chicken-hackers] Re: repository branching, (continued)
- Re: [Chicken-hackers] Re: repository branching, felix winkelmann, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, Alejandro Forero Cuervo, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, Alejandro Forero Cuervo, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, felix winkelmann, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, Peter Bex, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, felix winkelmann, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, Peter Bex, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, felix winkelmann, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching,
Peter Bex <=
- Re: [Chicken-hackers] Re: repository branching, felix winkelmann, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, Ivan Raikov, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, felix winkelmann, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, Ivan Raikov, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, Kon Lovett, 2008/02/26
- Re: [Chicken-hackers] Re: repository branching, Felix Winkelmann, 2008/02/23
- Re: [Chicken-hackers] Re: repository branching, Jim Bailey, 2008/02/23
- Re: [Chicken-hackers] Re: repository branching, Alejandro Forero Cuervo, 2008/02/25
- Re: [Chicken-hackers] Re: repository branching, Alex Shinn, 2008/02/22
- Re: [Chicken-hackers] Re: repository branching, felix winkelmann, 2008/02/22