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.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe