Version number in Windows oscar.exe has first three numbers same as string and fourth as 0
Version number in Windows installer has first three numbers same as string and fourth indicates build type:
0 = release, 100=alpha, 200=beta, 300=gamma, 400=rc
Release/RC version: no sandbox
Testing releases (tagged prerelease version): -test
Development builds: -branchname (if at the head of a branch)
-(commitid) (if in a headless state)
And in the unlikely event someone tries to build a non-release version
from a tarball instead of git, its sandbox will be "-unreleased".
This may require a tweak to look in the right directory for the
source code, but it will automatically format the version number
appropriately for Debian packaging.
The iteration number is now the only optional argument, defaulting
to 1.
The bash script now adds a #define if the current checkout is
exactly on a tag, and it leaves all #defines empty if building
from a tarball.
The batch file still needs to be updated.
This removes git dependencies from everything except for version.cpp,
and removes the associated interfaces in version.h.
Since the full version string contains the branch and revision
number where applicable, the build information no longer needs
to report branch and revision separately. It also now queries
version.cpp for a more consistent and reliable build time.
Debug output of build information is also now more consistent with
less redundant code.
The full version now includes the build/git information embedded within
it as build metadata according to the Semantic Versioning 2.0.0 spec,
for example: "1.1.0-beta-1+branch-name-a1b2c3d".
Now the full version string, with all detail is always displayed
EXCEPT for release versions, in which case just the simple version
number ("1.1.0") is displayed in the primary UI.
- Main window title: simple version for release versions, full version
string otherwise
- Notifications: same as main window title
- System tray: same as main window title
- About window title: same as main window title
- About window release notes: always include full version string
- Reports: always include full version string
- Under the logo (about dialog, profile selector, new profile
window): removed, as it is largely redundant and can
interfere with the window geometry.
- Database upgrade alert: same as main window title
- Database newer alert: same as main window title
The full version string is also included within the preference and
profile .xml files, but because build metadata is ignored in version
comparisons, differences in builds will not cause any spurious
alerts. However, changes in prerelease versions will continue to
be significant, as they should be.
Previously it was reporting spurious information when the humidifier was
disconnected. Now it only reports settings details when the humidifier is
connected (the only time they're valid.)
It also now reports the humidification mode (fixed, adaptive, or heated
tube), and the heated tube temperature when appropriate.
No real change to functionality, other than confirming correct behavior,
documenting observed data and adding flags for anything new.
The ParseHumidifierSettingF0V4 function has now been renamed to
ParseHumidifierSetting60Series for accuracy.
Accordingly update ParseHumidifierSetting50Series to add a parameter
controlling whether parsed settings should be imported or not,
consistent with all other PRS1 humidifier parsers.
The ParseHumidifierSettingV2 function has now been renamed to
ParseHumidifierSetting50Series for accuracy, and the code and
parameters which had been used when 60-Series machines (incorrectly)
relied on it has been removed.
The last statistics events in each slice are now correctly imported.
Previously, in the surprising edge case where two statistic periods are
reported with the same end-of-slice timestamp, they were both being duplicated
when marking the end of the slice.
Also, there were scattered instances where the final statistics in a slice
weren't being imported at all or were being imported incorrectly. These are
now fixed as well.
