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