when 3.0.11?

[Arran Cudbard-Bell]

> On Jan 11, 2016, at 9:09 AM, Michael Ströder <michael at stroeder.com> wrote:
> 
> Alan DeKok wrote:
>> On Jan 11, 2016, at 7:36 AM, Lucas Diaz <lucasdiaz at eternet.cc> wrote:
>>> 
>>> Ok, but is there another version after 3.0.10, stable at least? Or you're meaning 3.1.x branch?
>> 
>> I mean the v3.0.x development branch.  We don't release 3.0.10, and then
>> 3.0.11 the next day.
>> 
>> The code which will become 3.0.11 is in the v3.0.x development branch.  This
>> is how software development works.
> 
> Hmm, during the last months lurking here I noticed more and more postings
> recommending to get a fix from the v3.0.x development branch. Personally I
> consider it to be a bit error-prone and it also solves the issue just for a
> particular user asking for it. Other users will probably hit the same issue(s).
> 
> How about a bit more of release-early-release-often?
> (E.g. I'm willing to update the openSUSE development package right after your
> 3.0.11 release.)

We could just do away with software versions entirely.

If there is *ANY* difference in the number of known defects between your magic, tagged, blessed commits, and the commits that have been pushed to the main branch,  you're doing software development wrong.

The reason why will still have versions is largely psychological.  People like to see a monotonically increasing number, it gives them a feeling of progress.

They ignore the fact that running a version behind the current branch head, almost always ensures they're running software with known defects that have already been fixed.

They ignore the fact that only testing *after* a version has been released, increases dramatically, the length of time defects are present in the code base and the effort required to track down defects.

If you actually want to help the project, and not just be a passive consumer of the code we write, ignore the release tags entirely, setup a build script for v3.0.x, apply the latest build every Tuesday morning to a test server, and report any issues you find.

Yes, it will require extra effort, you'll likely want your *own* logic tests to ensure your service functions correctly,  but the end result will be a higher quality service for your users, and higher quality code in FreeRADIUS.

-Arran


Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20160111/f03db05c/attachment.sig>