[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: branch_release-1-4 brought into 21st century
From: |
Thien-Thi Nguyen |
Subject: |
Re: branch_release-1-4 brought into 21st century |
Date: |
Sat, 23 Feb 2002 12:20:42 -0800 |
From: Marius Vollmer <address@hidden>
Date: 23 Feb 2002 18:44:46 +0100
Thanks. We, however, should take care not have a confusing release
frenzy. I think 1.6 is close enough to be released that we probably
should not release a 1.4.1.
i have a different point of view. semi-rant: in light of the fact that
1.4 adoption has been slow (we continually hear "i just downloaded 1.4
and can't compile..."), it seems to me any release *no matter the
version* that follows the same process as 1.4 release will not be
liberating but instead be confusing, with the end result being even less
uptake. [insert rant here on how 1.4 broke hobbit -- we had a compiler
and THREW IT AWAY along with other things, like users.]
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).
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).
thi