| Re: [AD] set_config_file jumping around on OS X bundles |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: [AD] set_config_file jumping around on OS X bundles
- From: Matthew Leverton <meffer@xxxxxxxxxx>
- Date: Mon, 22 Aug 2005 14:57:09 -0500
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lfmN1eZG6bfQ5Q1PbwlArwHBJ0z0kGbFrqKoVU2qowzgtSWJSLySpIidW1qP1X4UToHL6TYyEfv8Pa2ZeaDmgcXvwG3t2TtgLz3bxay+Ox1bGcQp13SBGC/ho1N7SvMf77IaoYyrYSVQQVyRDnBzJMzc5nkpjhTDLQUvpM5fs6U=
> > That breaks backward compatibility? If so, could we agree on a dummy
> > entry that's not documented yet so we don't have to wait three or four
> > years for a proper fix to appear on a stable version?
>
> I'd rather not. I don't think there's much difference in adding a null
> vtable entry and adding one with functions filled in.
>
What exactly did removing the "forward" compatibility clause give us?
What updates can we make to the stable version?
I know this is another discussion in itself, but why do we bother
naming the DLL alleg42.dll if we know it just means the "stable"
branch will be for all practical purposes frozen in time for several
years, when we could name it allegro-4.2.0.dll and be done with it. I
would guess that this must still pose a problem to UNIX type of
environments?
I realize this topic has already been beaten to death, but it just is
disappointing to see the "stable" branch sit idle for years and years.
If we cannot change the frequency of stable branches, then I think we
really need to do a better job of informing people when the "stable"
version has become so old it's best off to use the development branch.
--
Matthew Leverton