It doesn't look like I mentioned it below, but I plan on creating the release-4.2 branch this upcoming Monday, the 25th. At that point we'll have the following active branches and major+minor versions:
master / 4.3
release-4.2 / 4.2
release-4.0 / 4.0
release-3.6 / 3.6
4.2.0rc1 is still scheduled for October 5 and the Windows and macOS installers will hopefully include Qt 6.5.3. 4.2.0 is still scheduled for November 15.
On 9/17/23 3:13 PM, João Valverde wrote:
I'm not sure I follow. I don't know why things would settle down before a branch is made. That's exactly my point, the master branch should be unaffected by the release schedule IMO. Things settle down after the branch is created, not before.
If the policy I outline before is followed there's no extra work, the churn just happens earlier instead, with 4.1 releases and not 4.2 (backports that are strictly bug fixes are not churn).
On 9/17/23 12:29, Jaap Keuter wrote:
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.
___________________________________________________________________________
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