Hi,
This starts to resemble the Linux kernel merge window challenges. There's always
a tradeoff between ease of development vs. churn. Things do need to settle down
before a branch can be made, that's what we're here for.
Personally I'm in the process of finalizing a new dissector (for iperf3) and
extending another (RTP headers in SAToP). That's my target for 4.2. Not an issue
to double submit, just a bit more hassle.
Jaap
On 9/16/23 01:02, João Valverde wrote:
I would like that. We can be liberal backporting changes to the 4.1 release, but
some care should be taken to avoid very big or risky changes. Then for the 4.2
release candidates, ideally only bugfixes would be backported.
On 9/15/23 22:51, Gerald Combs wrote:
I have no objections to creating the 4.2 branch earlier. As you point out, it
mostly comes down to how much backporting we want to do. The release numbers
are a reflection of the fact that "run tools/make-version.py -v ..." is in the
new release branch checklist.
On 9/15/23 12:06 PM, João Valverde wrote:
Should 4.1 be developed on the release-4.2 branch already? Obviously it would
require some backporting work from developers, but also provide some
stability. Right now the 4.1 release is just a snapshot of master, so really
4.1.x micro versions are meaningless.
There are some changes that might be too experimental to push on master right
now, given that a stable release is right around the corner.
By creating the release-4.2 branch earlier, I think that problem could be
avoided, and maybe also lead to a better 4.2 release.
Thoughts?
On 8/17/23 22:04, Gerald Combs wrote:
Hi all,
I'd like to start preparing for the creation of the release-4.2 branch and
the 4.2.0 release. I've come up with the following tentative schedule, which
will give us a couple of release candidates before SharkFest EU and a final
release in November, after SharkFest:
Aug 24 : Release 4.1.0
Aug ?? : Release 4.1.1
Sep ?? : Release 4.1.2
Oct 2 : Create the release-4.2 branch
Oct 4 : Release 4.2.0rc1
Oct 18 : Release 4.2.0rc2
Oct 30 - Nov 3 : SharkFest EU. See you in Brussels!
Nov 8 : Release 4.2.0
If you need to delay any of the above, particularly the release-4.2 branch,
please let me know.
New features and improvements in 4.2.0 will include:
- Packet list sorting performance improvements.
- "_ws.col.<x>" display filters.
- More display filter improvements, including raw byte matching (@field.name
== 12:ab:23:cd).
- Some name resolution files (such as "manuf" and "services") are now
compiled in, which reduces startup time.
- A built-in MAC address / OUI dialog.
- A Windows Arm64 installer.
Note that the release-3.6 branch is an LTS branch, so in accordance with
https://wiki.wireshark.org/Development/LifeCycle we'll have three active
release branches until May 2024.