I've taken a quick look at porting a few features from the CVS head to 1.0.x. Specifically, the new dictionaries, dictionary parser, and the weird VSA handling. So far, it looks like it works. Should I commit it to 1.0.x, for maybe 1.0.6? Or make a 1.1.x branch off of 1.0.x, and call the new code 1.1.0? It's been over a year since 1.0 was released, and having a 1.1.0 with a few new features would be cool. We could also back-port a few other things, like some of the module cleanups. These should be relatively easy to back-port, and can have significant useful impact for people running the server. In the mean time, the CVS head can continue with it's re-writes, and IPv6 work. Also, having a 1.1.0 with a few minor changes means that the step to 2.x is less problematic. Thoughts? Opinions? Rocks & bricks? Alan DeKok.
Alan DeKok wrote:
In the mean time, the CVS head can continue with it's re-writes, and IPv6 work.
This part I like. Especialy if it was open to more changes.
Also, having a 1.1.0 with a few minor changes means that the step to 2.x is less problematic.
I know I had few problems migrating to CVS head from 1.0.x What would be different? What more than a sdiff on radiusd.conf would be neccessary?
Thoughts? Opinions? Rocks & bricks?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Joe Maimon <jmaimon@ttec.com> wrote:
I know I had few problems migrating to CVS head from 1.0.x
Yeah, a bunch of modules changed.
What would be different?
Ideally, a bunch of minor tweaks to a bunch of modules. e.g. recent changes to rlm_files, rlm_attr_filter, to generalize them. Fixes in rlm_pap & rlm_ldap, to do more auto-discovery and require less admin configuration. Fixes to rlm_digest. New rlm_sql_log, and documentation. i.e. much of the work in the CVS head that's easy to back-port, but not the completely invasive changes live full IPv6 support. The idea is to have a release that's easy to do, and gets people part-way to 2.x, without making them change everything all at once.
What more than a sdiff on radiusd.conf would be neccessary?
Telling people to *read* the new radiusd.conf would help. Things like the "unix" module removing support for caching /etc/passwd, which I've never liked. Alan DeKok.
Hi,
Telling people to *read* the new radiusd.conf would help. Things like the "unix" module removing support for caching /etc/passwd, which I've never liked.
the usual way is to put some option in the radiusd.conf which must be commented out before the system will work - if the value is active the program quits with a message to the effect of 'read the configuration file' - but such a system has as many enemies as it does fans alan
On November 29, 2005 7:35:50 PM -0500 Alan DeKok <aland@ox.org> wrote:
The idea is to have a release that's easy to do, and gets people part-way to 2.x, without making them change everything all at once.
In my experience, this is a bad thing. Folks do not want to change their production enviroments more often than they have to. That's not an argument against 1.1.0. No one is forced to upgrade. I would like to see a 1.1.0 release. -frank
Frank Cusack <fcusack@fcusack.com> wrote:
In my experience, this is a bad thing. Folks do not want to change their production enviroments more often than they have to.
I agree. But if the work is spread out in small, low-risk changes, that's easier to manage than "throw away your existing config, and re-create it"
I would like to see a 1.1.0 release.
Ok. Alan DeKok.
Alan DeKok wrote:
I've taken a quick look at porting a few features from the CVS head to 1.0.x. Specifically, the new dictionaries, dictionary parser, and the weird VSA handling. So far, it looks like it works.
Sounds good.
Should I commit it to 1.0.x, for maybe 1.0.6? Or make a 1.1.x branch off of 1.0.x, and call the new code 1.1.0?
I'd prefer 1.1.0 rather than 1.0.6, even if I don't like branches of branches in CVS.
It's been over a year since 1.0 was released, and having a 1.1.0 with a few new features would be cool. We could also back-port a few other things, like some of the module cleanups. These should be relatively easy to back-port, and can have significant useful impact for people running the server.
There many, many changes in CVS that may go in 1.1.0. I can't tell all of them, but it includes: newer autotools, {Pre,Post}-Proxy-Type stanzas, support of ${Cisco-AVPair[n]} syntax, -n and -p options in radclient, changes in rlm_attr_filter, new rlm_sql_log & radsqlrelay... It'd be nice to have all of that in 1.1.0, but it'd mean to back-port a lot of things. I'm starting to think perhaps it's easier to branch CVS head and to downgrade a few files to undo IPv6 work (less than 10 files?) and some other things we keep for 2.0. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I'd prefer 1.1.0 rather than 1.0.6, even if I don't like branches of branches in CVS.
Yeah, I agree.
There many, many changes in CVS that may go in 1.1.0. I can't tell all of them, but it includes: newer autotools, {Pre,Post}-Proxy-Type stanzas, support of ${Cisco-AVPair[n]} syntax, -n and -p options in radclient, changes in rlm_attr_filter, new rlm_sql_log & radsqlrelay...
I'm OK with putting in things that are easy. If it's hard, let's punt. So newer autotools make me nervous, but much of the rest of what you said sounds OK.
It'd be nice to have all of that in 1.1.0, but it'd mean to back-port a lot of things. I'm starting to think perhaps it's easier to branch CVS head and to downgrade a few files to undo IPv6 work (less than 10 files?) and some other things we keep for 2.0.
That scares me even more than back-porting things. I think much of the back-porting can be done easily, or simplified by using monotone. I'll create the branch off of release_1_0, and start committing code. Alan DeKok.
Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I'd prefer 1.1.0 rather than 1.0.6, even if I don't like branches of branches in CVS.
Yeah, I agree.
There many, many changes in CVS that may go in 1.1.0. I can't tell all of them, but it includes: newer autotools, {Pre,Post}-Proxy-Type stanzas, support of ${Cisco-AVPair[n]} syntax, -n and -p options in radclient, changes in rlm_attr_filter, new rlm_sql_log & radsqlrelay...
I'm OK with putting in things that are easy. If it's hard, let's punt.
So newer autotools make me nervous, but much of the rest of what you said sounds OK.
It would be a good idea to start releasing beta versions to overcome the "nervosity". 1.1.0 = beta 1.1.1 = stable 1.1.2 = beta 1.1.3 = stable 2.0.0 = beta 2.0.1 = stable ... -- Groeten, Regards, Salutations, Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
I would agree with this, however we should likely follow a more common versioning approach... like major.minor.release where the minor version number is odd for beta and even for stable or just major.minor for stable and major.minor(b)release (ie 2.0b1) for betas. --Mike Thor Spruyt wrote:
Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I'd prefer 1.1.0 rather than 1.0.6, even if I don't like branches of branches in CVS.
Yeah, I agree.
There many, many changes in CVS that may go in 1.1.0. I can't tell all of them, but it includes: newer autotools, {Pre,Post}-Proxy-Type stanzas, support of ${Cisco-AVPair[n]} syntax, -n and -p options in radclient, changes in rlm_attr_filter, new rlm_sql_log & radsqlrelay...
I'm OK with putting in things that are easy. If it's hard, let's punt.
So newer autotools make me nervous, but much of the rest of what you said sounds OK.
It would be a good idea to start releasing beta versions to overcome the "nervosity".
1.1.0 = beta 1.1.1 = stable 1.1.2 = beta 1.1.3 = stable 2.0.0 = beta 2.0.1 = stable ...
-- Groeten, Regards, Salutations,
Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com
www.salesguide.be www.telenethotspot.be
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Michael Griego <mgriego@utdallas.edu> wrote:
I would agree with this, however we should likely follow a more common versioning approach... like major.minor.release where the minor version number is odd for beta and even for stable or just major.minor for stable and major.minor(b)release (ie 2.0b1) for betas.
Sure. 1.1.x is for new features. If it looks good, we can release 1.2 with only bug fixes. Alan DeKok.
On December 1, 2005 8:34:11 AM -0600 Michael Griego <mgriego@utdallas.edu> wrote:
I would agree with this, however we should likely follow a more common versioning approach... like major.minor.release where the minor version number is odd for beta and even for stable or just major.minor for stable and major.minor(b)release (ie 2.0b1) for betas.
Don't we do that already? 1.1 is newer than 1.0, etc. Please god, no even/odd numbering. -frank
Not really... Many projects have unstable releases that still don't include the absolute latest code. Like Allen said earlier, 1.1 would be for adding all sorts of new features, and it could break your machine, but its still a "release"... 1.2 would be only bugfixes to the new features added to 1.1 and should be considered production quality, meaning any problems would take higher priority than problems with odd numbered releases. --Mike Frank Cusack wrote:
On December 1, 2005 8:34:11 AM -0600 Michael Griego <mgriego@utdallas.edu> wrote:
I would agree with this, however we should likely follow a more common versioning approach... like major.minor.release where the minor version number is odd for beta and even for stable or just major.minor for stable and major.minor(b)release (ie 2.0b1) for betas.
Don't we do that already? 1.1 is newer than 1.0, etc.
Please god, no even/odd numbering.
-frank - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
The better way to do that is to tag dev releases 'b' or 'a' or whatever. I guess you did say that. But FR hasn't been in the habit of issuing beta or dev releases other than CVS head. So it's not that we haven't been following a common versioning approach, we've just never formally released dev code. -frank On December 1, 2005 5:19:27 PM -0600 Michael Griego <mgriego@utdallas.edu> wrote: > Not really... Many projects have unstable releases that still don't include the absolute latest > code. Like Allen said earlier, 1.1 would be for adding all sorts of new features, and it could > break your machine, but its still a "release"... 1.2 would be only bugfixes to the new features > added to 1.1 and should be considered production quality, meaning any problems would take higher > priority than problems with odd numbered releases. > > --Mike > > Frank Cusack wrote: >> On December 1, 2005 8:34:11 AM -0600 Michael Griego >> <mgriego@utdallas.edu> wrote: >>> I would agree with this, however we should likely follow a more >>> common versioning approach... >>> like major.minor.release where the minor version number is odd for >>> beta and even for stable or >>> just major.minor for stable and major.minor(b)release (ie 2.0b1) for >>> betas. >> >> Don't we do that already? 1.1 is newer than 1.0, etc. >> >> Please god, no even/odd numbering. >> >> -frank >> - List info/subscribe/unsubscribe? See >> http://www.freeradius.org/list/devel.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Frank Cusack <fcusack@fcusack.com> wrote:
The better way to do that is to tag dev releases 'b' or 'a' or whatever. I guess you did say that. But FR hasn't been in the habit of issuing beta or dev releases other than CVS head. So it's not that we haven't been following a common versioning approach, we've just never formally released dev code.
My goal in splitting the work over multiple releases is to get the pieces tested in isolation. We know that the current 1.0.x libtool, configure, etc. works. It may be a pain, but it works. First, I'd like to get more RADIUS functionality in 1.1.x, then upgrade the auto* tools. I don't think anyone's going to upgrade past 1.0.x if the next rev has little more than autoconf updates. And adding multiple features to the same release makes me wary, which is one reason I haven't been pushing hard for a 2.0. Alan DeKok.
Alan DeKok wrote:
There many, many changes in CVS that may go in 1.1.0. I can't tell all of them, but it includes: newer autotools, {Pre,Post}-Proxy-Type stanzas, support of ${Cisco-AVPair[n]} syntax, -n and -p options in radclient, changes in rlm_attr_filter, new rlm_sql_log & radsqlrelay...
I'm OK with putting in things that are easy. If it's hard, let's punt.
So newer autotools make me nervous, but much of the rest of what you said sounds OK.
Autotools are bothering, but there're so many problems related to the obsolete version in release 1.0.x that it looks it's worth to upgrade. I also note that libtool1.4 package is broken in current Debian, therefore it's hell to build FreeRADIUS now.
It'd be nice to have all of that in 1.1.0, but it'd mean to back-port a lot of things. I'm starting to think perhaps it's easier to branch CVS head and to downgrade a few files to undo IPv6 work (less than 10 files?) and some other things we keep for 2.0.
That scares me even more than back-porting things.
It was just a suggestion. I'll start to work on the back-port of the mentioned features (except autoconf) as soon as I happen to have some time. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Autotools are bothering, but there're so many problems related to the obsolete version in release 1.0.x that it looks it's worth to upgrade.
That scares me... How about doing a 1.1.0 with code changes, and leaving autotools & libtool updates to 1.1.1?
I also note that libtool1.4 package is broken in current Debian, therefore it's hell to build FreeRADIUS now.
Ok... I just remember going through hell trying to update libltdl & libtool in the CVS head.
It was just a suggestion. I'll start to work on the back-port of the mentioned features (except autoconf) as soon as I happen to have some time.
OK. Alan DeKok.
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Frank Cusack -
Joe Maimon -
Michael Griego -
Nicolas Baradakis -
Thor Spruyt