On Thu, 3 May 2018 10:07:27 +0100 Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Thu, May 03, 2018 at 08:21:00AM +0100, Stefan Hajnoczi wrote: > > On Wed, May 02, 2018 at 09:02:00AM +0100, Daniel P. Berrangé wrote: > > > On Wed, May 02, 2018 at 09:44:03AM +0200, Gerd Hoffmann wrote: > > > > Hi, > > > > > > > > > > If we bump the major version each year anyway, why not go the whole > > > > > > way > > > > > > and use 2018.1, 2018.2, ... (or even <year>.<month>)? The nice thing > > > > > > about that is that you can see at a glance when the release took > > > > > > place. > > > > > > > > > > ... or simply drop the first two digits and call them 18.1, 18.2, > > > > > ...? > > > > > > > We could also drop the major/minor scheme altogether (as they are > > > > meaningless anyway) and just go for YYMM, i.e. 1808 (for a august > > > > release). > > > > > > I don't much like that - it'll lead to a wierd progression of numbers > > > where we'll be constantly the rationale re-explaining to people who > > > want to know why we've jumped from 1808 to 1902 to 1905 etc > > > > I don't see an issue with time-based numbering schemes. Ubuntu made it > > popular and other projects (like DPDK) are doing the same thing now. > > > > The convention is YY.MM though, not YYMM. > > It feels like we've got quite a strong backing for time based versioning > amongst people replying here. I'd be happy with YY.MM FWIW, both YY.MM and YYYY.MM look fine to me.