denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Schneider
Subject: Re: [Denemo-devel] Changing the way we use version numbers in Denemo
Date: Fri, 23 Dec 2016 17:15:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1

An alternative would be to introduce an additional fourth number for the
development versions, e.g. representing the date. For instance, a build
from today would be 2.1.15.20161223.

At the moment, I am setting the version of my builds by hand. In
principle, this can be automated (one has to add certain lines in the
copyright file). Can the Debian developers on the list please comment if
there is a standardised way to automatically adapt version numbers?

Andreas


Am 23.12.2016 um 16:31 schrieb Richard Shann:
> 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 change will come at an opportune moment, since the next release is
> intended to remove Gtk deprecated code, which will place us in a good
> position for GTK4. The only caveat is the threading primitives which are
> deprecated - I don't understand that code, so I'm not sure if I will
> succeed in moving it on. I wonder if we could crowd-fund a threading
> expert to do this?
> 
> Richard




reply via email to

[Prev in Thread] Current Thread [Next in Thread]