From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Jiri Pirko <jiri@resnulli.us>
Cc: kuba@kernel.org, davem@davemloft.net, netdev@vger.kernel.org,
b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [PATCH 1/5] batman-adv: Start new development cycle
Date: Thu, 2 Feb 2023 19:44:06 +0100 [thread overview]
Message-ID: <Y9wEdn1MJBOjgE5h@sellars> (raw)
In-Reply-To: <Y9faTA0rNSXg/sLD@nanopsycho>
On Mon, Jan 30, 2023 at 03:55:08PM +0100, Jiri Pirko wrote:
> Fri, Jan 27, 2023 at 11:21:29AM CET, sw@simonwunderlich.de wrote:
> >This version will contain all the (major or even only minor) changes for
> >Linux 6.3.
> >
> >The version number isn't a semantic version number with major and minor
> >information. It is just encoding the year of the expected publishing as
> >Linux -rc1 and the number of published versions this year (starting at 0).
>
> I wonder, what is this versioning good for?
The best reason in my opinion is that it's useful to convince
ordinary people that they should update :-).
Usually when debugging reported issues one of the first things we ask
users is to provide the output of "batctl -v":
```
$ batctl -v
batctl debian-2023.0-1 [batman-adv: 2022.3]
```
If there is a very old year in there I think it's easier to tell
and convince people to try again with newer versions and to
update.
And also as a developer I find it easier to (roughly) memorize
when a feature was added by year than by kernel version number.
So I know by heart that TVLVs were added in 2014 and multicast
snooping patches and new multicast handling was added around 2019
for instance. But don't ask me which kernel version that was :D.
I'd have to look that up. So if "batctl -v" displayed a kernel
version number that would be less helpful for me.
Also makes it easier for ordinary users to look up and
compare their version with our news archive:
https://www.open-mesh.org/projects/open-mesh/wiki/News-archive
Also note that we can't do a simple kernel version to year
notation mapping in userspace in batctl. OpenWrt uses the most
recent Linux LTS release. But might feature a backport of a more
recent batman-adv which is newer than the one this stable kernel
would provide. Or people also often use Debian stable but compile
and use the latest batman-adv version with it.
Does that make sense?
next prev parent reply other threads:[~2023-02-02 18:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-27 10:21 [PATCH 0/5] pull request for net-next: batman-adv 2023-01-27 Simon Wunderlich
2023-01-27 10:21 ` [PATCH 1/5] batman-adv: Start new development cycle Simon Wunderlich
2023-01-30 7:40 ` patchwork-bot+netdevbpf
2023-01-30 14:55 ` Jiri Pirko
2023-02-02 18:44 ` Linus Lüssing [this message]
2023-02-03 8:29 ` Jiri Pirko
2023-02-03 9:38 ` Sven Eckelmann
2023-02-07 9:02 ` Leon Romanovsky
2023-02-07 9:50 ` Sven Eckelmann
2023-02-07 10:41 ` Leon Romanovsky
2023-02-07 10:57 ` Sven Eckelmann
2023-02-07 11:20 ` Leon Romanovsky
2023-01-27 10:21 ` [PATCH 2/5] batman-adv: Drop prandom.h includes Simon Wunderlich
2023-01-27 10:21 ` [PATCH 3/5] batman-adv: Fix mailing list address Simon Wunderlich
2023-01-27 10:21 ` [PATCH 4/5] batman-adv: mcast: remove now redundant single ucast forwarding Simon Wunderlich
2023-01-27 10:21 ` [PATCH 5/5] batman-adv: tvlv: prepare for tvlv enabled multicast packet type Simon Wunderlich
-- strict thread matches above, loose matches on Subject: below --
2020-08-24 16:27 [PATCH 0/5] pull request for net-next: batman-adv 2020-08-24 Simon Wunderlich
2020-08-24 16:27 ` [PATCH 1/5] batman-adv: Start new development cycle Simon Wunderlich
2020-04-27 15:06 [PATCH 0/5] pull request for net-next: batman-adv 2020-04-27 Simon Wunderlich
2020-04-27 15:06 ` [PATCH 1/5] batman-adv: Start new development cycle Simon Wunderlich
2019-11-05 9:35 [PATCH 0/5] pull request for net-next: batman-adv 2019-11-05 Simon Wunderlich
2019-11-05 9:35 ` [PATCH 1/5] batman-adv: Start new development cycle Simon Wunderlich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9wEdn1MJBOjgE5h@sellars \
--to=linus.luessing@c0d3.blue \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=davem@davemloft.net \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).