btw, you can look on freeradius-protobif module, which have functionality very close to rlm_rest (generic bridge but for protobuf over http instead rest) and have supported branch for freeradius-2.1 (see https://github.com/rssh/rlm_protobuf/ - master is compatible with 3.0, freeradius-2.1.x - with 2.1.x) This work in production for my of one clients. On Sat, Aug 11, 2012 at 6:34 PM, Gavin Alves <gavin.alves@gmail.com> wrote:
how do you designate 'mature' software? old software can and does have bugs too - well used software might be 'mature' in way of updates/patches but then you have no features. we need more people to be running 3.0 so that we can find any other issues and maybe see a sooner release or 3.0.1 etc
I've only running 3.0 HEAD on my test systems now - no longer looking at 2.1.x or 2.2.x updates - and it wont be long before it'll be just 3.x on production systems too.
Point taken. The reality is that many organisations will not upgrade software until there are packages maintained in their distro, By this point a business can assume at least some minimum standard of 3rd party quality assurance and peer review. A really strong case would be needed for a home brew release (which I don't think I could make as 2.1 works very well for us).
As for getting people onto 3.0; a classic catch 22. Updating the website, api docs, distributing binary packages and so on might help. I was not even aware of it until yesterday.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html