2.1.8 and 2.2.0

[Joe Maimon]

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
> features.
> 
>   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 
over time.

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 
project itself.

Joe