Is it worth having two versions of the server? i.e. releasing 2.1.8 *and* 2.2.0 at the same time? The reason is that current "stable" branch contains some fairly major changes (TCP), and more are on the way. The next things involve changing the internal API, which pretty much mandates a 2.2.0. However, there are also a number of bug fixes which could go into 2.1.7 and any following release. The question then is, do we want to have BOTH: 2.1.8 = 2.1.7 + bug fixes ONLY 2.2.0 = major new features + any fixes OR, do we want to give up on 2.1.8, and just release 2.2.0? There are pros and cons both ways. Having a stable 2.1.8 is good. But maintaining two versions could confuse people. Alan DeKok.
I guess, that better name 2.2.0 as 2.2.0-beta ([release 2.1.8 and 2.2.0-beta at same time, later rerelease 2.2.0 during next month or two)
Is it worth having two versions of the server? i.e. releasing 2.1.8 *and* 2.2.0 at the same time?
The reason is that current "stable" branch contains some fairly major changes (TCP), and more are on the way. The next things involve changing the internal API, which pretty much mandates a 2.2.0.
However, there are also a number of bug fixes which could go into 2.1.7 and any following release.
The question then is, do we want to have BOTH:
2.1.8 = 2.1.7 + bug fixes ONLY
2.2.0 = major new features + any fixes
OR, do we want to give up on 2.1.8, and just release 2.2.0?
There are pros and cons both ways. Having a stable 2.1.8 is good. But maintaining two versions could confuse people.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Hi,
The question then is, do we want to have BOTH:
2.1.8 = 2.1.7 + bug fixes ONLY
2.2.0 = major new features + any fixes
OR, do we want to give up on 2.1.8, and just release 2.2.0?
There are pros and cons both ways. Having a stable 2.1.8 is good. But maintaining two versions could confuse people.
we already have 2 versions that people get confused and want support on.. 1.x and 2.x (in fact, you could say 1.0.x, 1.1.x, 2.0.x and 2.1.x ! :-) ) however, i would be happy to have 2.1.8 and 2.2.0 for the short term - because 2.1.x train is one that everyone is familiar with and works in the 2.1.x way where-as - as you say, 2.2.x will have new features, methods etc - it would make sense , then to say 2.1.8 for the small upgraders and 2.2.x for those wanting the new features/methods etc. ..and can we say goodbye to all 1.x 'support' ? :-) alan
Alan Buxey wrote:
we already have 2 versions that people get confused and want support on..
Version numbers keep going up, not down.
however, i would be happy to have 2.1.8 and 2.2.0 for the short term - because 2.1.x train is one that everyone is familiar with and works in the 2.1.x way where-as - as you say, 2.2.x will have new features, methods etc - it would make sense , then to say 2.1.8 for the small upgraders and 2.2.x for those wanting the new features/methods etc. ..and can we say goodbye to all 1.x 'support' ? :-)
Ok.... We can do 2.1.8 with minor changes over 2.1.7. Then, 2.2.0 with major changes (TCP, etc.) Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Alan Buxey wrote:
we already have 2 versions that people get confused and want support on..
Version numbers keep going up, not down.
however, i would be happy to have 2.1.8 and 2.2.0 for the short term - because 2.1.x train is one that everyone is familiar with and works in the 2.1.x way where-as - as you say, 2.2.x will have new features, methods etc - it would make sense , then to say 2.1.8 for the small upgraders and 2.2.x for those wanting the new features/methods etc. ..and can we say goodbye to all 1.x 'support' ? :-)
Ok.... We can do 2.1.8 with minor changes over 2.1.7. Then, 2.2.0 with major changes (TCP, etc.)
So, how long before I can type 'make menuconfig' eh? :) 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. Cheers -- Alexander Clouter .sigmonster says: Never argue with a woman when she's tired -- or rested.
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.
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
Joe Maimon wrote:
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.
:) Added complexity means that old assumptions are no longer true, and need to be re-visited.
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.
As of earlier this year, my *sole* income is FreeRADIUS. That's nice, but it's taken 10 years...
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.
Git makes it a *lot* easier. 5 minutes of reviewing patches, and I have a version that is 2.1.7 + fixes, *without* any of the TCP or other work. Very nice.
I do think some of the oldest trains could stop running already.
Oh, yes. Everyone running 1.0 should upgrade.
Thank you Alan for all your hard work, both here on the lists and on the project itself.
I'm incentivized now to do *more*. I've been meaning to do more on the DHCP side, and it looks like I might have the opportunity... Alan DeKok.
Alan DeKok wrote:
Joe Maimon wrote:
As of earlier this year, my *sole* income is FreeRADIUS. That's nice, but it's taken 10 years...
Congrats and kudos. My best wishes you much success now and in the future.
I'm incentivized now to do *more*.
I've been meaning to do more on the DHCP side, and it looks like I might have the opportunity...
Alan DeKok. -
I was quite surprised to even see the DHCP work. Its pretty novel and interesting to think of implementing freeradius for an enterprise DHCP system. Thanks again for all your help and efforts. Joe
participants (5)
-
Alan Buxey -
Alan DeKok -
Alexander Clouter -
Joe Maimon -
Ruslan Shevchenko