[quagga-dev 14717] Re: Proposed Versioning

Donald Sharp sharpd at cumulusnetworks.com
Tue Feb 23 12:54:17 GMT 2016


I tried to be very vague in what constitutes a major -vs- minor for just
the reasons you outlined.  I wanted the person doing the work to have some
flexibility to apply some brain cells for what is right.  If we can agree
that we have brain cells and that we can use them I think I'm ok with
leaving major and minor very vaguely defined.

I'm neither here nor there with date in the version, I was just proposing
it.  I guess it really comes down to the people doing the work to
ultimately decide.  I'll get up with you, Paul, offline and we can discuss
it further and then send a note to the alias with a conclusion.

donald

On Tue, Feb 23, 2016 at 5:38 AM, Paul Jakma <paul at jakma.org> wrote:

> On Tue, 16 Feb 2016, Donald Sharp wrote:
>
> In today's Monthly meeting we briefly discussed how we would like to
>> version Quagga going forward.  Two proposals were put forward, a date
>> based
>> version string or a Major.Minor.Bug version string.  I'd like to propose
>> that we combine the two of them together and get this:
>>
>> Major.Minor.YYYYMMDD
>>
>> Major = Major restructuring/Feature added to the system, VRF comes to
>> mind.
>> Minor = Minor restructuring/Feature added to the system.  The MTR code
>> changes or the zebra refactoring that has been going on comes to mind.
>> YYYYMMDD =
>>    YYYY  - The Year of the release
>>    MM - The Month of the release
>>    DD - The Day of the month of the release
>>
>> In the unlikely event we need to release a bug fix on the same date add
>> something like a -1 to the end, or wait till tommorrow.
>>
>
> ;)
>
> A little comment. We often tend not to do "major" v "minor" releases. Just
> releases, as and when they are needed. Also, some daemons might have major
> changes in a release, and others minor. Some fixes may be minor to one
> user, major to another. It's really hard to make a globally consistent
> determination of wht is "major" and what is "minor".
>
> Possibly "new features or compatibility breaks" v "bug fixes to existing
> features" is a distinction we could sort of make.
>
> On date, I've long used the CONFDATE to put the date configured was run
> into the version string of RPMs built from within Quagga, along with a
> 2-digit revision suffix (to deal with the 'same date' issue).
>
> That said, I'm not sure I want the date in the version. :) I'd prefer just
> bumping a number.
>
> Not very helpful, I know, sorry.
>
> regards,
> --
> Paul Jakma      paul at jakma.org  @pjakma Key ID: 64A2FF6A
> Fortune:
> Harp not on that string.
>                 -- William Shakespeare, "Henry VI"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20160223/7b0697ec/attachment-0001.html>


More information about the Quagga-dev mailing list