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.
Hi Gerald,
Look good for the planned release
I hope only to have time to integrate the support of HTTP3 headers (with
nghttp3) -> https://gitlab.com/wireshark/wireshark/-/merge_requests/9330
Cheers
On Thu, Aug 17, 2023 at 11:04 PM Gerald Combs wrote:
> Hi all,
>
> I'd like to start preparing
Hi,
In the last weeks I started using Wireshark more and noticed some
crashes. I hope to be able to look into it over the next two weeks, and
also address some QUIC issues. Not sure if I will be able to review the
HTTP/3 changes in time.
Do you think it is better to branch, and then cherry-pick,
On 8/24/23 13:16, Peter Wu via Wireshark-dev wrote:
Hi,
In the last weeks I started using Wireshark more and noticed some
crashes. I hope to be able to look into it over the next two weeks, and
also address some QUIC issues. Not sure if I will be able to review the
HTTP/3 changes in time.
Do
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 migh
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 Valv
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
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)
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
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 schedul
The release-4.2 branch has been created.
On 9/21/23 3:41 PM, Gerald Combs wrote:
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
11 matches
Mail list logo
