guile-devel
[Top][All Lists]
Advanced

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

Re: branch_release-1-4 brought into 21st century


From: Rob Browning
Subject: Re: branch_release-1-4 brought into 21st century
Date: Sat, 23 Feb 2002 15:58:49 -0600
User-agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i386-debian-linux-gnu)

Thien-Thi Nguyen <address@hidden> writes:

> in any case, it is critical that we get people off of 1.3.4 and at least
> up to 1.4, if we want to reduce long-term maintenance burden and yet
> maintain mindshare.  some repackagers (like redhat apparently) have
> strict policies on migration, and refuse to go to 1.4 (even) for
> whatever reasons.  1.4.x is for them (they won't even look at 1.6.x).

At least on this front, I suspect that there's a good chance that they
might go straight to 1.6 or 1.4, whichever's available when they
decide to make the next effort, and then there would be another long
waiting period before the next jump.  But it's also possible you're
right and they would be comfortable with 1.4, but refuse 1.6.  I'd
really like to see Debian and Red Hat move straight to 1.6, and
according to my testing, they should be able to -- gnucash and guppi
should be fine, and if not, I'm willing to fix whatever's still
broken.  In any case, I'm planning to see if the RedHat people would
like me to help them package 1.6.

I don't feel strongly wrt 1.4.1 either way, though everyone should
keep in mind that we do have limited manpower and we need to make sure
to keep it focused where it matters most -- getting releases out,
adding features, improving documentation, and handling backward
compatibility are all important, and we're going to have to strike a
balance.

> conversely, those not bound to 1.3.4 will probably adopt 1.6.x no
> problem and happily ignore 1.4.x.  so, i don't predict much confusion
> arising from parallel 1.4.x and 1.6.x releases, and plan to stay the
> course w/ 1.4.x.  i encourage others to work on quick 1.5.x and
> quick/methodical 1.6.x releases.  all i ask is for some room in the
> libguile CURRENT space for API backfill purposes (see other post on
> small steps).

Presuming we do release 1.4.1, I'm just fine with this.  I'm going to
make the appropriate changes to CURRENT in 1.5 and HEAD regardless.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD



reply via email to

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