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, duck
On Fri, 22 Feb 2008 12:34:36 +0100 Peter Bex <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 22, 2008 at 02:38:25AM -0800, Alejandro Forero Cuervo wrote:
> > So what about the idea of adding a (supported-releases 2.3 3.0.0) tag
> > to the meta file, where particular versions of an egg that needs to do
>
On Fri, Feb 22, 2008 at 02:38:25AM -0800, Alejandro Forero Cuervo wrote:
> So what about the idea of adding a (supported-releases 2.3 3.0.0) tag
> to the meta file, where particular versions of an egg that needs to do
> so specify which is the range of Chicken releases it supports?
Actually, this
> 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
hi
On 21 Feb 2008, at 8:13 pm, Alejandro Forero Cuervo wrote:
What percentage of the eggs do we really expect to require different
code for each Chicken release? I would imagine that the percentage is
very small, but I don't really know...
I'd hope it to be few, and would want to handle it with
> To keep egg sources for released but old versions, with the option
> of maintaining them. It's quite frustrating (as all of us know), that if
> I reinstall some eggs (say on a new machine), and those eggs
> use features that are only supported in newer chickens.
So what about the idea of adding
On Thu, Feb 21, 2008 at 9:13 PM, Alejandro Forero Cuervo
<[EMAIL PROTECTED]> wrote:
>
> Umm, what's the motivation for this?
To keep egg sources for released but old versions, with the option
of maintaining them. It's quite frustrating (as all of us know), that if
I reinstall some eggs (say on a
> This change is not only inconsistent with the way most svn
> repositories tend to be used and redundant with the standard practices
> of /tags and /branches, but it puts a burden on the maintainers, when
> I think we ought to be striving for the opposite goal. Maintainers
> are short on time; we
> Please note that from now on you have to chose for which release you
> want eggs to be updated: any commits to the old egg directories (as
> well as creating new egg directories) will be only available for pre
> 3.0.0 chickens. Chickens version 3.0.0rc1 and higher donwload eggs
> from a different
