sounds like a good idea.
Enterprise distros are always behind, this won't stop them from updating any
more than they already do, and will make it clear how old it is.
Just as a note, if there is a same-day bugfix, just post-date it (use the next
day's date), that will only cause problems if there is a long series of
one-a-day-or-more bugfixes, and if that happens, we have far bigger problems
than the version number. :-)
David Lang
On Sat, 15 Dec 2018, Rainer Gerhards wrote:
Date: Sat, 15 Dec 2018 13:19:33 +0100
From: Rainer Gerhards <[email protected]>
Reply-To: rsyslog-users <[email protected]>
To: rsyslog-users <[email protected]>
Subject: [rsyslog] rsyslog version numbering change
Hi all,
as you know, rsyslog uses a version number scheme of
8.<real-version>.0
where we increment <real-version> every 6 weeks with each release. The
8 and 0 are constant (well, the 0 could change to 1 with a very
important patch, but in practice we have only done this once).
While this scheme has worked pretty well since we introduced it, I
often see people not understanding that there is really a big
difference between 8.24 and e.g. 8.40. Looking at recent trends in
software versioning, we see
a) single-number versions, e.g. in systemd
This is actually what we use, except that we make it look like
and old-style version number by the prefix 8 and suffix 0.
b) date-based versions, e.g. by distros (Ubuntu 18.04)
I would like to make a bold move and change rsyslog's version to
yyyy.mm.dd
of the actual release date. That makes it crystal-clear how old a
version is and also removes any ambiguity between daily builds and
official releases. Bug fix releases can also be easily done as we
never ever had two of them at the same day.
That means the next releases would not be
8.41.0 and 8.42.0 but rather 2019.01.22 and 2019.03.05.
A drawback of the change is that possible enterprise distributions
will not package any 2019+ releases until their next major release,
but I would be willing to accept this in preference of better clarity
for the user.
If there is no hard objection, I'll change the version scheme with 2019.01.22.
Any concerns please let me know.
Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
