2.1.8 and 2.2.0
jmaimon at ttec.com
Fri Oct 23 15:06:29 CEST 2009
Alan DeKok wrote:
> Alexander Clouter wrote:
>> So, how long before I can type 'make menuconfig' eh? :)
> Much of that is already in the code. Many of the features can be
> removed at build time:
> - threads
> - accounting
> - proxying
> - dhcp
> - vmps
>> I am personally for a single version but with some ifdef uglyness for
>> experimental bits that is enabled by default. If people want different
>> 'trains' then they could just learn how to use git and be done with
>> it....at least they can then use 'git bisect' too.
> The issue is more that major changes to the code can affect production
> systems. It's safer for the production systems to have limited fixes to
> a "stable" release, and then to have a "feature" release that adds new
> Alan DeKok.
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Especially with this project. Its amazingly stable considering how
complex it has gotten and the features that keep getting shoved in. Alan
loves rewriting code he doesnt like, and he seems to dislike lots of it
Personally, I have always chosen to use the latest bits being worked on
at the time of project deployment and further maintenance usually means
a complete redeployment. A few patches, recompile, repackage, rewrite of
config and off we go.
Any critical production system wishing to upgrade should retain the
services of a competent freeradius engineer to ensure it all goes
smoothly, not like it cant without it, but some of us could use the income.
In a sense, that is what distributions are supposed to be doing, so
retiring old trains but keeping them alive for critical fixes is a very
nice and responsible thing to be doing to help them out.
If a bit tedious and annoying as well.
I do think some of the oldest trains could stop running already.
Thank you Alan for all your hard work, both here on the lists and on the
More information about the Freeradius-Devel