I'm indifferent, to be quite honest, how the version numbers work and what
I download, so long that there is a difference and things become more solid
with both enhancements and fixes.. Set the file name and revisions to a
date, for all that it matters to me, or just label is as
SQLite3.dll/.zip/.so/.etc. But I'm kind of siding on what Marc is getting
at.
Lets say that a new function is added. Y gets bumped to Y+1 (Call it Y1)
and Z is reset to 0.
Another new function is added, Y gets bumped again to Y+1 (Call it Y2) and
Z is again reset to 0 and now Y1 is considered irrelevant.
What happens when something is discovered wrong with the first function?
This update to the function introduced in Y1 doesn't have anything to do
with Y2, so is Z going to get bumped?
(This is my personal general conundrum with how team based revision systems
work with GIT, SVN, and now even Fossil. If something found new today that
was introduced three revisions ago, whats the count get set to?)
My $0.02 comes down to scrap the whole major/minor/build version system and
go with something more concrete using build dates. So 3.201508151235.
This would point that 3 is for file structure for SQLite3 while the build
date contains whatever has been put into code. At the source code level
for individual files, my SCR automatically bumps up the version number.
All in all, with single or multiple changes, only affects the final output
of the build process.
What the minor and build versions mean is subject to change and offer an
air of confusion. With a 3.{Date} version, you get a concrete "This is the
day the product was built with all features and known bug fixes". And it'd
be just as easy for people to report "Between 201510081205 and 201512101500
I have this problem..." Bit harder to read, come to think of it.....
