Maybe a 1.1.0?

classic Classic list List threaded Threaded
17 messages Options
| Threaded
Open this post in threaded view
|

Maybe a 1.1.0?

Alan DeKok
  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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Joe Maimon


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
>
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Alan DeKok
Joe Maimon <[hidden email]> 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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

A.L.M.Buxey
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Nicolas Baradakis
In reply to this post by 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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Frank Cusack
In reply to this post by Alan DeKok
On November 29, 2005 7:35:50 PM -0500 Alan DeKok <[hidden email]> 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Alan DeKok
In reply to this post by Nicolas Baradakis
Nicolas Baradakis <[hidden email]> 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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Alan DeKok
In reply to this post by Frank Cusack
Frank Cusack <[hidden email]> 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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Thor Spruyt
In reply to this post by Alan DeKok
Alan DeKok wrote:

> Nicolas Baradakis <[hidden email]> 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: [hidden email]
W: www.thor-spruyt.com

www.salesguide.be
www.telenethotspot.be

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Nicolas Baradakis
In reply to this post by 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

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Michael Griego
In reply to this post by Thor Spruyt
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 <[hidden email]> 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: [hidden email]
> W: www.thor-spruyt.com
>
> www.salesguide.be
> www.telenethotspot.be
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
>  
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Alan DeKok
In reply to this post by Nicolas Baradakis
Nicolas Baradakis <[hidden email]> 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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Alan DeKok
In reply to this post by Michael Griego
Michael Griego <[hidden email]> 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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Frank Cusack
In reply to this post by Michael Griego
On December 1, 2005 8:34:11 AM -0600 Michael Griego <[hidden email]> 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
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Michael Griego
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
> <[hidden email]> 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
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Frank Cusack
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 <[hidden email]> 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
>> <[hidden email]> 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




-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Maybe a 1.1.0?

Alan DeKok
Frank Cusack <[hidden email]> 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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html