Re: Maybe a 1.1.0?

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