Version.h not used?

[NicoHood]

https://github.com/abcminiuser/lufa/blob/master/LUFA/Version.h

Is this used somehere? I cannot find a real use case, also the variables are zero and dont contain a version. Setting a version could be useful for further projects that rely on a specific lufa version.

[abcminiuser]

Hi Nico,

(I know, I still have a bunch of issues you've raised I need to reply to - unfortunately my Buck's night was last Saturday and I am still a little under the weather shall we say...)

The intention is (and, assuming I ran my validation scripts every time I made a release) that the version header is set to the correct version when an official package is made. This allows user applications to check and throw an error or adjust their behavior to changing APIs or patch around bugs.

I know a lot of people are using LUFA as a Git submodule or directly via a fork, but I can't think of a good way to semantically version that would make sense. Two options would be to just keep the last release value populated (in which case subsequent changes until the next release might cause problems) or increment it every time I make a change (which would be untenable).

[NicoHood]

if you write the number in amarican style a newer date is a higher number. If you do a release, you can change the number to the new date. For the master branch I then would use the data + 1 day. So you can always do

#if version > 2015XXXX

This would also work with submodules :)

[abcminiuser]

I do use ISO 8601 date format encoding (such as 160102 for the second day of the first month of 2016) when the field is populated for exactly that reason :). The issue is letting the value go stale, in that there might be breaking changes made to the LUFA tree since the last release was made, which means existing projects that probe the LUFA version would noisily break without failing a version check.

Resetting it to 0 for in-development versions prevents stale values from confusing people, but I do realize that many people prefer to work on a non-tagged git checkout rather than an official release. Is it better perhaps to use two values LUFA_VERSION_INTEGER and LUFA_IS_RELEASE_TYPE where the former takes on the last official release's value, and the latter is populated with a sentinal for full releases, beta releases and in-development versions perhaps?

[NicoHood]

Yes. Just use a bool for release version true, false. You should not update the data every time though, to not spam the commits. As suggested I'd just use the day after the release.

[abcminiuser]

Fixed in https://github.com/abcminiuser/lufa/commit/9669a00c34dc7545b2ca538b5aa0fde745483824. I've added a new LUFA_VERSION_RELEASE_TYPE constant which will be set to LUFA_VERSION_RELEASE_TYPE_DEVELOPMENT unless it is a beta/full release. The existing LUFA_VERSION_INTEGER and LUFA_VERSION_STRING values will retain their current values for all development releases, and be updated for beta/full releases.