[hpsdr] Firmware version numbering

[Joe Martin K5SO]

Hi Gordon, 

Yes, there certainly is value in coming to some kind of agreement in how to assign version numbers to firmware that gets developed.  However, it's a more complex issue than you might suspect.  Here are few of the issues that need to be considered: 

1)  Your suggestion of making the version number 3.1.1 would seem to be rational but actually the specific example you suggest for Mercury won't work, at least not with the present number of bits we have allowed for version numbers.  Without getting into too much detail, we have, in principle, only 255 values that can be assigned for version numbers.  A version number of 3.1 uses a value of 31 in the Verilog code, a version number of 3.2 would use a value of 32, etc.  So you can see that your specific example of assigning a 3.1.1 can't work, as the number 311 exceeds the allowed values.  The situation is even more complex than that as we have elected to use one of the bits in the version number reporting to indicate whether the Mercury ADC is in overload condition or not.  That reduces the "available" values left for version numbering to a (small) max value of 128.  Therefore, in the current scheme for version numbers, the maximum version number we can use is v12.x, with a maximum "sub" version number usually running from .0 to .9, but in the max case of 128 the version number would be 12.8.  

2)  If we implement some overall scheme for version number assignments someone will have to volunteer to manage the process and be the "overseer" of assignments of code from all developers.  Perhaps you would like to take on such a task?  Even if you are willing, there needs to be some kind of "rework" of the details of how many bits we will choose to work with in the Verilog code, as the independent version information needs to be passed from each board to the PC.   

3)  Jeremy and a small group of other developers, including me, have considered this issue in the form of limited-scope discussions via email recently.  The problem is not a trivial one in fact.  When I indicated that I would be making some new, special purpose, firmware available for multiple-Mercury users we finally decided that for the time being my present action of assigning "crazy" version numbers may be the better solution, at least until such time as we, as a group, wish to address establishing a formalized procedure.  This type of administrative management doesn't excite me personally very much so I'm certainly not a good choice as the "overseer" for such a process.  Perhaps someone will step up with a sensible way to handle the assignments of version numbers to code from multiple developers?  

4)  In the interim, and with most in agreement (or at least not strongly objecting), it was decided that I should simpluy continue with my "crazy" version numbering until such time as it becomes problematic due to the "running out" of available numbers or there arising so many developers that such a process becomes a nightmare.  At least, for now, when you see a version number that is clearly out of sequence from the "official" version numbers it should indicate to you that something very different exists with that version.  

If you, or others, would like to think about this issue carefully and make a recommendation to the group as to how to resolve it,  it would be most welcome, keeping in mind some the technical (granted, somewhat arbitrary) limitations that we presently have imposed upon ourselves. 

73,  Joe K5SO



 
On Jan 25, 2012, at 3:52 PM, Gordon & Lois Duff wrote 
> ***** High Performance Software Defined Radio Discussion List *****
> 
> Joe,
>  
> It seems like there is value in establishing a protocol for firmware versioning.  It would be nice to know that Mercury v7.0 is the same as Mercury v3.1 except it only supports one RX stream.  Maybe your v7.0 should be v1.3.1, indicating branch 1, version 3.1. 
>  
> Perhaps the problem is theoretical as Mercury's FPGA seems to be full, but the concept might apply to future boards and firmware.
>  
> Gordon, KA2NLM
>  
>  
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20120125/63d1cb92/attachment-0004.htm>