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