[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Re: [Chicken-hackers] Re: repository branching
From: |
Alaric Snell-Pym |
Subject: |
Re: [Chicken-users] Re: [Chicken-hackers] Re: repository branching |
Date: |
Fri, 22 Feb 2008 11:52:43 +0000 |
On 22 Feb 2008, at 10:56 am, Alejandro Forero Cuervo wrote:
I'd hope it to be few, and would want to handle it with a suitable
macro around the afflicted bits of code, rather than duplicating the
whole source file...
Yes, that'd seem a more reasonable approach, I'd have to say...
Alejo, ducking to avoid the rotten oranges that Felix will throw at
him!
:-)
I'd expect that currently written eggs would be written for whatever
version of Chicken the egg author had installed when they started,
and that they'd tag it with this information somehow in the .meta
file or whatever (or, if they're feeling like the effort, actually
looking up what features they use and when they came in, and working
out the minimum version they actually require).
THEN when they upgrade to a new release, and use a snazzy new
feature, they can do either:
(require chicken-2-9)
...where all subsequent versions of chicken that remain backwards
compatible to 2.9 will still accept that, or:
or... what's it called... that thing that works like C's #ifdef.
Something-case. Can't find it in the manual. Use that to select
between different implementations for different versions, so they can
use snazzy features that provide more speed or features, while
falling back to old code if it's not available.
I think I see Felix's point - *if* you consider the version-specific
copies of the eggs as tags of the egg repository at that point in
time, when they all worked with that version of chicken, and only
ever modify them if a critical bug is found therein. However, this
means that, as a blanket definition, old releases of chicken can't
use newer eggs at all, unless the egg maintainer goes to special
efforts to make them available by backporting them.
In which case, I'd take the eggs in / to be "current", and just tag
them off for a release of chicken *before* releasing the new chicken.
Eg, when 3.0 is released, the current set of eggs become the 2.9
'basket', and are tagged for prosperity somewhere. Then 3.0 comes out
and people rewrite all their eggs to use the amazing new "call-with-
free-biscuit" macro...
*browse*
Hmmm, I always find fun things when I start looking in the Chicken
manual. case-lambda. Must remember that one. It'd be cool if it let
you put constants and stuff in the cases, destructuring bindings
always make functions that recurse over data structures particularly
lovely. Ah, match-lambda* exists! Drool...
ABS
--
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/?author=4