On Oct 28, 2015, at 9:53 AM, Jorge Pereira <jpereiran@gmail.com> wrote:
exist roadmap for v3.1.x?
We don't have a definitive roadmap. We do have plans, though. Until now, we've tried hard to stay with C99 standards for the server. This is good for backwards compatibility, as there are many people running weird OSes, or old OSes. That backwards compatibility is now a problem. To solve this, we will move the 3.1 branch to using the latest C11 standard. This means thread-local storage, C99 initializers, C11 atomics, etc. All of these features make it easier for us to maintain the server. So anyone running RedHat 6 is sol. Sorry, but that's life. If you're running FreeRADIUS on OpenWRT, you can continue to run version 2. It won't be maintained, but it works, and doesn't have known problems. It's fine for embedded use. If you're an ISP, enterprise, university, etc. You can continue to run whatever you're running. If there's a problem with v2, though, our response will be "upgrade". New installations should use version 3. People wishing magical new features should install the v3.1.x branch from git. When we think it's ready, we'll start a 3.2 release series. We *don't* want to confuse people by offering multiple "stable" versions of the server. There's only one "stable" version: version 3. The version 2 release is "long term support", which will likely end this year. Alan DeKok.
On 28 Oct 2015, at 10:13, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 28, 2015, at 9:53 AM, Jorge Pereira <jpereiran@gmail.com> wrote:
exist roadmap for v3.1.x?
We don't have a definitive roadmap. We do have plans, though.
Until now, we've tried hard to stay with C99 standards for the server. This is good for backwards compatibility, as there are many people running weird OSes, or old OSes. That backwards compatibility is now a problem.
We should also start removing compatibility fixes for versions of software released before 2011.
To solve this, we will move the 3.1 branch to using the latest C11 standard.
* we have moved. It won't build on systems with compilers without C11 support. Support for old style pthread based thread-local storage has been removed. Some of the shim code is still there to provide destructors on thread exit.
This means thread-local storage, C99 initializers, C11 atomics, etc. All of these features make it easier for us to maintain the server.
So anyone running RedHat 6 is sol. Sorry, but that's life.
Unless you run clang, which does implement the basic features of C11 on RHEL6. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Oct 28, 2015, at 10:20 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
We should also start removing compatibility fixes for versions of software released before 2011.
Most of that is gone in 3.1. In 3.0, it complained about the use of deprecated configuration items. In 3.1, it ignores the old ones entirely. Alan DeKok.
On 28 Oct 2015, at 10:23, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 28, 2015, at 10:20 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
We should also start removing compatibility fixes for versions of software released before 2011.
Most of that is gone in 3.1. In 3.0, it complained about the use of deprecated configuration items.
In 3.1, it ignores the old ones entirely.
More stuff like this: /* * glibc 2.4 and uClibc 0.9.29 introduce IPV6_RECVPKTINFO etc. and * change IPV6_PKTINFO This is only supported in Linux kernel >= * 2.6.14 * * This is only an approximation because the kernel version that libc * was compiled against could be older or newer than the one being * run. But this should not be a problem -- we just keep using the * old kernel interface. */ #ifdef __linux__ # ifdef IPV6_RECVPKTINFO # include <linux/version.h> # if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,14) # ifdef IPV6_2292PKTINFO # undef IPV6_RECVPKTINFO # undef IPV6_PKTINFO # define IPV6_RECVPKTINFO IPV6_2292PKTINFO # define IPV6_PKTINFO IPV6_2292PKTINFO # endif # endif /* Fall back to the legacy socket option if IPV6_RECVPKTINFO isn't defined */ # elif defined(IPV6_2292PKTINFO) # define IPV6_RECVPKTINFO IPV6_2292PKTINFO # endif #else -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
It won't build on systems with compilers without C11 support.
Support for old style pthread based thread-local storage has been removed. Some of the shim code is still there to provide destructors on thread exit.
This means thread-local storage, C99 initializers, C11 atomics, etc. All of these features make it easier for us to maintain the server.
So anyone running RedHat 6 is sol. Sorry, but that's life.
Unless you run clang, which does implement the basic features of C11 on RHEL6.
Or build yourself a non-prehistoric version of GCC. (along with the many dependencies it requires) I've been using 3.1 on RHEL 6.4 for a while now, it builds and works fine. :) This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
I guess there's no definitive one as predicting the future is hard ;) If any cool new features get proposed or submitted for 3.1.x then it seems it's fine. They'll just go in (and not into 3.0.x) . Are you after timescales for release or timescales for features? alan
On Oct 28, 2015, at 1:28 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
If any cool new features get proposed or submitted for 3.1.x then it seems it's fine. They'll just go in (and not into 3.0.x) . Are you after timescales for release or timescales for features?
v3.1x already has new features. The "map" function has been needed for a long time. The redis module has support for redis clusters. And lots of code cleanups. Lots and lots and lots... Alan DeKok.
participants (5)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Chaigneau, Nicolas -
Jorge Pereira