Update on 3.0, 3.1, and 3.2.
We plan on releasing 3.0.12 on Monday. it's stable, and there no new issues being reported for it. This will ideally be the last release of the 3.0 series. Version 3.0 was released almost three years ago, and it's time for a new major version of the server. 3.1 supports a "map" keyword, redis cluster, and many other useful features. Many people have been using the 3.1 branch in production, so we're confident that it is stable and functional. To keep things simple, we don't release an official 3.1 version. Instead, we will call 3.1 a "development / experimental" branch. Once we're ready (later this summer), we'll release an official 3.2 release. The v3.1.x branch will then be frozen, and no further development will occur on it. All new development will then start with a 3.3 branch, which will likely turn into version 4.0. There are enough architecture changes needed that it warrants a 4.0. In summary: 2.1 and earlier: dead. Don't use them. 2.2: Only critical security fixes. We expect this won't happen. 3.0: stable. New installations can use 3.0. 3.1: development. Use it only if you know what you're doing. 3.2: (future stable). Mid 2016 on, new installations should use this. 3.3. (future development), more changes, with a goal of increasing performance substantially.
On 05/26/2016 10:53 PM, Alan DeKok wrote:
We plan on releasing 3.0.12 on Monday. it's stable, and there no new issues being reported for it.
This is good news, thanks for your work! Is there still a chance to get my pull request through? This one: https://github.com/FreeRADIUS/freeradius-server/pull/1592 Nick
On May 27, 2016, at 4:56 AM, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:
Is there still a chance to get my pull request through? This one:
That's a patch which is very OS-specific. I think it's best left for the individual OS packagers. i.e. it's not needed elsewhere, so I'm wary of including it in the server. If the patch could go into the "redhat/" directory, and be applied prior to a RedHat build, that would be best. Alan DeKok.
On 05/27/2016 05:45 PM, Alan DeKok wrote:
On May 27, 2016, at 4:56 AM, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:
Is there still a chance to get my pull request through? This one:
That's a patch which is very OS-specific. I think it's best left for the individual OS packagers.
i.e. it's not needed elsewhere, so I'm wary of including it in the server.
If the patch could go into the "redhat/" directory, and be applied prior to a RedHat build, that would be best.
Alright, I'll redo it to go into "redhat/" and will update the pull request. It can then go into the next release. Thanks, Alan! Nick
Hi Alan, On 05/27/2016 04:45 PM, Alan DeKok wrote:
On May 27, 2016, at 4:56 AM, Nikolai Kondrashov <Nikolai.Kondrashov@redhat.com> wrote:
Is there still a chance to get my pull request through? This one:
That's a patch which is very OS-specific. I think it's best left for the individual OS packagers.
i.e. it's not needed elsewhere, so I'm wary of including it in the server.
If the patch could go into the "redhat/" directory, and be applied prior to a RedHat build, that would be best.
I had some time to return to this, and I'd like to argue for inclusion of this patch again. First, this is not very OS-specific. This is a problem on all Linux distros. The version-less libraries are only for development, and at runtime you shouldn't expect them to be present and load the fully-versioned library instead. For example, on Debian Testing, without libpython2.7-dev installed, I get the same issue: # Instantiating module "python" from file /etc/freeradius/3.0/mods-enabled/python Python version: 2.7.13 (default, Jan 19 2017, 14:48:08) [GCC 6.3.0 20170118] Failed loading libpython symbols into global symbol table: libpython2.7.so: cannot open shared object file: No such file or directory Second, even if we add it as a build-time patch, it will be a pain to maintain, especially since it touches "configure" and "config.h.in" files, which are generated. I'll rebase my patch and will wait for your answer. Thank you. Nick
Hi Alan, Is the summary in your message from May still accurate? In my last thread a couple of people mentioned 3.1, but I don't really want to run a development branch in production. I'm building a new dev VM for a config re-write and I'm trying to decide which version to go with. Thanks, Dave On 16-05-26 03:53 PM, Alan DeKok wrote:
We plan on releasing 3.0.12 on Monday. it's stable, and there no new issues being reported for it.
This will ideally be the last release of the 3.0 series. Version 3.0 was released almost three years ago, and it's time for a new major version of the server. 3.1 supports a "map" keyword, redis cluster, and many other useful features.
Many people have been using the 3.1 branch in production, so we're confident that it is stable and functional. To keep things simple, we don't release an official 3.1 version. Instead, we will call 3.1 a "development / experimental" branch.
Once we're ready (later this summer), we'll release an official 3.2 release. The v3.1.x branch will then be frozen, and no further development will occur on it.
All new development will then start with a 3.3 branch, which will likely turn into version 4.0. There are enough architecture changes needed that it warrants a 4.0.
In summary:
2.1 and earlier: dead. Don't use them.
2.2: Only critical security fixes. We expect this won't happen.
3.0: stable. New installations can use 3.0.
3.1: development. Use it only if you know what you're doing.
3.2: (future stable). Mid 2016 on, new installations should use this.
3.3. (future development), more changes, with a goal of increasing performance substantially. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Fri, Sep 16, 2016 at 02:49:15PM -0400, Dave Aldwinckle wrote:
Is the summary in your message from May still accurate?
http://lists.freeradius.org/pipermail/freeradius-devel/2016-August/011999.ht... and http://lists.freeradius.org/pipermail/freeradius-devel/2016-September/012028...
In my last thread a couple of people mentioned 3.1, but I don't really want to run a development branch in production.
Many of us do, but latest 3.0 is best if you're not comfortable with that.
I'm building a new dev VM for a config re-write and I'm trying to decide which version to go with.
It's easily possible to write a config that will work on both 3.0 and 3.1 if you don't use any new features in 3.1. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.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>
participants (4)
-
Alan DeKok -
Dave Aldwinckle -
Matthew Newton -
Nikolai Kondrashov