Re: [Denemo-devel] Changing the way we use version numbers in Denemo

[Richard Shann]

On Fri, 2016-12-23 at 11:05 -0600, Jeremiah Benham wrote:
> 
> 
> On Dec 23, 2016 9:42 AM, "Richard Shann" <address@hidden>
> wrote:
>         I've been thinking that we should change the way we augment
>         the Denemo
>         version number, to avoid those who are following the
>         development having
>         problems when they upgrade but the version number stays fixed.
>         (And to
>         make better use of the numbers available).
>         
>         I propose that each release in future augments the minor
>         version number
>         (except if we ever create a major new version of course, in
>         which case
>         we would augment the major version number). So the next
>         release will be
>         2.1.0
>         after that the development version will become 2.1.1 and the
>         last number
>         can be augmented whenever the menu-system has been altered and
>         whenever
>         there is some significant change that it would be useful to
>         have
>         labelled. To avoid any confusion, I propose the micro-version
>         numbers
>         should skip even numbers for development versions - so once I
>         have the
>         current work ready I'll commit it with version set to 2.0.17
>         and
>         continue on the odd numbers until we are ready to release
>         2.1.0
>         
>         Jeremiah, Andreas, Tobias, Edgar - is this workable? - will
>         your
>         overnight builds continue to work ok as the version number
>         changes?
> 
> 
> This should all be fine. Do you want the overnight builds to be given
> a filename other than 0.0.0? Maybe we can have configure tell us the
> compile date so we can create like a build number for the snapshots.
> 
Well, there would be an advantage to the filename having the Denemo
version number in it. 
At the moment, the only way to be sure that an overnight build has a
feature that was committed that day is to download and test the feature.
Take the case of yesterday's commit: a serious crash fixed. In the new
regime I would have augmented the micro version number with that commit,
so that anyone reporting the same bug in future could be told what the
minimum version number is to fix it. As it is, with "overnight" being
not very specific I generally wait a day before telling people they can
download a fixed or enhanced version.

But that is icing on the cake... if the actual version number is not
readily accessible to your build script, the filename could be
hand-coded as 2.0.x which people would readily understand was some
version in the development 2.0.1, 2.0.3, 2.0.5 ... series. That would
need updating at each release (2.1.x etc). But 0.0.0 is okay too, and
never needs updating.


Richard

>