limpkin / mooltipass

Github repository dedicated to the mooltipass project

https://www.themooltipass.com

521 stars 113 forks source link

Build/Version information should be present in firmware #77

Closed jnwatts closed 10 years ago

jnwatts commented 10 years ago

Some kind of reproducible identifier should be present in the firmware, perhaps accessible via the GUI. I would suggest:

If built from git, use git describe
If built from release (I know, we don't have one yet), use version.h or something that is committed with source

For even more "interesting" suggestions, take a look at the linux kernel's method for determining versions/hashes: https://github.com/torvalds/linux/blob/master/scripts/setlocalversion

limpkin commented 10 years ago

We'll use

define MOOLT_VERSION_MAJOR 0x00

define MOOLT_VERSION_MINOR 0x01

in defines.h, output to the plugin

harlequin-tech commented 10 years ago

It might be good to add build number that updates for each change. E.g version 0.1.34 where 34 is the build number. This will allow finer-grained tracking of issues and behaviours.

limpkin commented 10 years ago

agreed... can I change the case CMD_VERSION : accordingly?

jim17 commented 10 years ago

Yes, I would suggest naming the 34 (from 1.0.34) as the PATCH version, and it should be incremented on a bug fix.

jnwatts commented 10 years ago

Not just bug fixes, but any time a new build is released: to the mailing list, future website, etc. (Obviously not updated if code is unchanged in any way)

For the developers we should be aware of the git hash from which we last built. On Aug 11, 2014 1:09 PM, "Miguel BT" notifications@github.com wrote:

Yes, I would suggest naming the 34 (from 1.0.34) as the PATCH version, and it should be incremented on a bug fix.

— Reply to this email directly or view it on GitHub https://github.com/limpkin/mooltipass/issues/77#issuecomment-51809619.

jim17 commented 10 years ago

When new feature is added I would recommend to increase the MINOR version number.