[hpsdr] Versioning Machpsdr and Auto firmware update for MacHPSDR

[Jeremy McDermond]

On Aug 11, 2010, at 5:27 PM, John James wrote:

> Jeremy,
> "versioning numbers":
> I think you should rethink your version numbering system. I think every runtime program should carry a version number that distinguished it from other versions however slight changes maybe in them. Then when you find a run time version in the wild you could tell what features are included in it. 
> 
> You seem to change your version number very rarely. I suggest you revise it so that the current number 
> 0.1.0.013 would be 0.1.13.N. Each of your recent updates would have a new N value. When you are ready for a new release you would change the 13 to a 14.

I only change version numbers when I make a binary release.  I tag the SVN tree at this point in time, and you can see all the source for the various versions in the SVN tags directory.

People compiling the SVN source are expected to know what they're doing, and have the skill to keep track of what's going on with the code.  When I commit something to SVN, it's not a new version, it's merely an SVN commit.  The SVN commits aren't even guaranteed to compile, let alone function correctly.  SVN isn't a distribution mechanism, it's change control.  It's released to the public for a couple of reasons:  (1)  So that those coding on the project can commit to a central repository of the "master" code when necessary, and (2)  So that those wishing to watch what's going on, or be on the bleeding edge, can get the very latest code.

That being said, every source code file in the repository carries information about its version.  For example, at the top of XTPanAdapterView.m you'll see something like:

"// $Id: XTPanAdapterView.m 151 2010-08-06 13:48:39Z mcdermj $"

This indicates that this file is from SVN revision 151.  You can go directly to the repository and figure out information about that version.  It also contains information about who made the last commit and when.

Also consider that the version number isn't just semantics.  The Sparkle Updater and MacOS itself look at the CFBundleVersion key in the application properties file for various things.

> "Auto Update of firmware" suggestion":
> I was wondering how the firmware update was coming along. I think this is a great Idea and am looking forward as a MacHPSDR user to using it. (I have not heard any discussion of the topic recently on Teamspeak.)

There hasn't been a lot of work on it.  It requires changes from Phil in the Ozy I firmware to implement, and I haven't gotten together with him to finalize those yet.

> I have a suggestion of how it might work a little differently than what you have described. Instead of automatically updating to the "Latest" version. Maybe it could have a popup menu that would come up and allow the user to select from a list of versions. Any new program start up would start with the popup at the last version installed but would allow for easy selection of newly downloaded versions. 
> 
> This would allow users to easily select spiffy but side versions of the FPGA code like Bill's recent WSPR code (PennyWSPR) for Penny. It may not be the main line version but the user may want to select his version with his call etc.

The loader in MacHPSDR wasn't intended to be "general purpose" like that.  It was always intended to load up versions of the firmware that are compatible with the version of MacHPSDR that you're running.  You can, of course, change out the versions contained in the application bundle by copying new stuff in.  I don't think your idea is a bad one.  I think it's more in the realm of a "stand-alone" firmware loader, rather than as functionality that's integrated into MacHPSDR.  Much of the code could be reused.

> 
> John - k1ym
> 

--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj at xenotropic.com




 1281639837.0