FreeRADIUS 3.1 estimated release date
Is there an estimated date for the release of FreeRADIUS 3.1.x? We're interested in the new caching features. Thanks, Jonathan
On Wed, Feb 17, 2016 at 01:07:42PM +0000, Jonathan Gazeley wrote:
Is there an estimated date for the release of FreeRADIUS 3.1.x? We're interested in the new caching features.
Just use it :) We've got it running live for one or two (fairly critical) services. To begin with I would just make sure you've got an easy roll-back in case there are and problems, and services like that should be wrapped in some type of daemon auto-restart system anyway in case something breaks in the night. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 17/02/16 13:32, Matthew Newton wrote:
On Wed, Feb 17, 2016 at 01:07:42PM +0000, Jonathan Gazeley wrote:
Is there an estimated date for the release of FreeRADIUS 3.1.x? We're interested in the new caching features.
Just use it :)
We've got it running live for one or two (fairly critical) services. To begin with I would just make sure you've got an easy roll-back in case there are and problems, and services like that should be wrapped in some type of daemon auto-restart system anyway in case something breaks in the night.
Thanks for the data point. Our RADIUS servers are overseen by Puppet, which would restart the daemon if it breaks, and thanks to the magic of VM snapshots then the rollback isn't too bad. I am reasonably confident in running 3.1.x from git but convincing my boss is going to be the issue! Maybe I just won't tell him :) Cheers, Jonathan
On Wed, Feb 17, 2016 at 01:41:30PM +0000, Jonathan Gazeley wrote:
Thanks for the data point. Our RADIUS servers are overseen by Puppet, which would restart the daemon if it breaks, and thanks to the magic of VM snapshots then the rollback isn't too bad. I am reasonably confident in running 3.1.x from git but convincing my boss is going to be the issue! Maybe I just won't tell him :)
I said I was upgrading to version 3. I didn't specify exactly which "version 3". ITIL is teaching me to keep my mouth shut more often. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Feb 17, 2016, at 8:07 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
Is there an estimated date for the release of FreeRADIUS 3.1.x? We're interested in the new caching features.
As Matthew said, just use it. We want to get 3.2 out this year. The problem is that things keep getting in the way. :( Alan DeKok.
On Wed, Feb 17, 2016 at 08:37:15AM -0500, Alan DeKok wrote:
On Feb 17, 2016, at 8:07 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
Is there an estimated date for the release of FreeRADIUS 3.1.x? We're interested in the new caching features.
As Matthew said, just use it.
We want to get 3.2 out this year. The problem is that things keep getting in the way. :(
But the more testers the better :) Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Just use 3.1.x HEAD , i believe that the plan is that 3.2.x will come from that and there won't be a specific 3.1 release anyway. We're using 3.1.x because of feature requirements....we'll probably slide to 3.2.x when that release occurs but right now the only issue is keeping track of where in the 3.1.x HEAD we are ;) .... ie to be able to roll back should a git pull result in a non compilable version or one with a big bug ( as Alan says, it's only through people using it that issues are found. ...That's a process we are part of ) alan
On Feb 17, 2016, at 11:34 AM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Just use 3.1.x HEAD , i believe that the plan is that 3.2.x will come from that and there won't be a specific 3.1 release anyway. We're using 3.1.x because of feature requirements....we'll probably slide to 3.2.x when that release occurs but right now the only issue is keeping track of where in the 3.1.x HEAD we are ;) .... ie to be able to roll back should a git pull result in a non compilable version or one with a big bug ( as Alan says, it's only through people using it that issues are found. ...That's a process we are part of )
When we're done with v3.1.x coding, we will release 3.2.0, which will be taken from the v3.1.x branch, and renamed. We will then start developing on the v3.3.x branch, of new unstable code. Alan DeKok.
participants (4)
-
Alan Buxey -
Alan DeKok -
Jonathan Gazeley -
Matthew Newton