Hi Gerald, Bálint Réczey <[email protected]> ezt írta (időpont: 2025. nov. 20., Cs, 20:29): > > Hi Gerald, > > Bálint Réczey <[email protected]> ezt írta (időpont: 2025. jan. > 10., P, 15:11): > > > > Hi Gerald, > > > > Gerald Combs <[email protected]> ezt írta (időpont: 2025. jan. 10., P, > > 1:23): > > > > > > On 1/7/25 6:20 AM, Bálint Réczey wrote: > > > > Hi Gerald, > > > > > > > > Gerald Combs <[email protected]> ezt írta (időpont: 2024. dec. 31., > > > > K, 0:37): > > > >> > > > >> Our current tag syntax wasn't really based on a grand plan. As > > > >> described at > > > >> > > > >> https://lists.wireshark.org/archives/wireshark-dev/201401/msg00194.html > > > >> > > > >> the "wireshark-" tags were created during the migration from > > > >> Subversion to git, and the "v" tags were created afterward to tag our > > > >> releases and release candidates. The "v" prefix was chosen because > > > >> it's commonly-used for version tags. It wouldn't require too much > > > >> effort on our end to switch from the "v" prefix to "wsv", but I'm not > > > >> sure how it would affect downstream users. > > > >> > > > >> I'd like to avoid adding "stratoshark-" tags simply because we already > > > >> have a bunch of tag types and tags, but that might not be possible. I > > > >> tried dropping the "wireshark-" tags for the same reason but at least > > > >> one distribution uses them for downstream monitoring: > > > >> > > > >> https://lists.wireshark.org/archives/wireshark-dev/201903/msg00000.html > > > > > > > > Thanks, I have switched to monitoring "v" tags since then, thus feel > > > > free to drop the "wireshark-" tags from my side. Sorry for not > > > > bringing this up earlier. > > > > > > > >> No one has objected to the "ssv0.9.0rc0" tag for 8140ad525b so far. > > > >> I'll create that in a bit since it's required for the upcoming 0.9.0 > > > >> release. > > > >> > > > >> On 12/29/24 3:21 AM, Jaap Keuter wrote: > > > >>> Hi, > > > >>> > > > >>> How much conflict would it create to ‘enhance’ the tag format > > > >>> throughout? I’m not particularly found of having a temporal influence > > > >>> on the format. > > > >>> > > > >>> Would the following work, avoiding ambiguity: > > > >>> - Release tags: wireshark-/x.y.z/ / stratoshark-/x.y.z/ > > > >>> - Release tags: wsv/x.y.z/ / ssv/x.y.z/ > > > >>> - RC tags: wsv/x.y.z/rc/n/ / ssv/x.y.z/rc/n/ > > > >>> > > > >>> Thanks, > > > >>> Jaap > > > >>> > > > >>>> On 26 Dec 2024, at 23:17, Gerald Combs <[email protected]> wrote: > > > >>>> > > > >>>> Hi all, > > > >>>> > > > >>>> I'm working on the Stratoshark release roadmap and have landed on > > > >>>> the following schedule: > > > >>>> > > > >>>> Jan 15 Stratoshark 0.9.0 > > > >>>> Jan 29 Stratoshark 0.9.1 > > > >>>> February, March, and April: more 0.9.x releases > > > >>>> May 21 Stratoshark 1.0 > > > >>>> > > > >>>> In the near term this will provide releases with stable URLs ahead > > > >>>> of my FOSDEM talks in early February and ensure that our release > > > >>>> infrastructure has the necessary plumbing for Stratoshark. Releasing > > > >>>> 1.0 in May is somewhat arbitrary but it would be nice to have that > > > >>>> done before SharkFest US. > > > >>>> > > > >>>> As part of this I plan on adding a new git tag prefix for > > > >>>> Stratoshark. We currently use the prefix "v" for Wireshark releases > > > >>>> and release candidates, e.g. "v4.4.2" for the Wireshark 4.4.2 > > > >>>> release and "v4.4.3rc0" for the 4.4.3 automated builds. I'd like to > > > >>>> add the tag prefix "ssv" for Stratoshark releases and release > > > >>>> candidates, with the initial tag "ssv0.9.0rc0" pointing to commit > > > >>>> 8140ad525b. Tag v4.5.0rc0 points to the same commit, which will > > > >>>> ensure that automated Stratoshark builds have contiguous "additional > > > >>>> commit" numbers after adding the new tag. > > > > > > > > Since Stratoshark is newly developed in the Wireshark repository I > > > > understand why a sub-1.0 version number reflects its maturity better > > > > and why frequent early releases could be beneficial for early > > > > adopters. > > > > Going forward OTOH it would be way easier if we just bumped > > > > Stratoshark's version to match Wiresharks' and release Stratoshark > > > > with Wireshark like we do with tshark and other related tools. > > > > > > > > That would avoid the problem of dealing with wireshark and stratoshark > > > > using the same shared libraries (libwireshark, libwiretap, libwsutil), > > > > but requiring different versions. This may not be a problem where > > > > everything is bundled, like on Windows, but for Linux distribution it > > > > would be something to work out. > > > > > > > > What do you think? > > > > > > As you point out, sub-1.0 versions are an effective way of communicating > > > the maturity level of the project and lets us iterate releases quickly, > > > which is crucial right now. Having a separate tag prefix is needed for > > > this. > > > > > > I think it's also important to have a 1.0 release in order to make it > > > clear that Stratoshark is ready for general use. I had assumed that we > > > would want to release Stratoshark 1.0 separately from Wireshark 5.0, but > > > as you point out that would be problematic for anyone trying to package > > > them together, so it probably makes sense to tie the Stratoshark 1.x and > > > Wireshark 5.x releases together. Having a separate tag prefix would be > > > counterproductive at this point. > > > > > > Maybe we should have three phases: A pre-1.0 phase with independent > > > versions and tag prefixes, a 1.0 phase with independent versions but with > > > the standard "v" tag prefix, and a post-1.0 phase, where we bump the > > > Stratoshark version Sun-style[1] to match the Wireshark version. The > > > schedule would look something like this: > > > > > > Jan 10: Stratoshark 0.9.0rc1, tagged as ssv0.9.0rc1 > > > Jan 15: Stratoshark 0.9.0, tagged as ssv0.9.0 > > > Jan 29: Stratoshark 0.9.1, tagged as ssv0.9.1 > > > Feb-Apr: More Stratoshark 0.9.x releases as needed, tagged as ssv0.9.x > > > May ??: Wireshark 5.0.0rc0 + Stratoshark 1.0.0rc0, tagged as v5.0.0rc0 > > > Jun ??: Wireshark 5.0.0 + Stratoshark 1.0.0, tagged as v5.0.0 > > > > This makes perfect sense, thanks! > > There is one more thing. Stratoshark's version needs to be bumped with > each Wireshark release, because Wireshark 4.6.0 shipped Stratoshark > 0.9.3 and now Wireshark 4.6.1 ships Stratoshark 0.9.3, too, with > minimally different content. > > In addition to this being odd on its own in Debian now two source > packages with different source version generate the same stratoshark > binary package with 0.9.3-1 version, that will most likely make the > second be rejected from the archive, the first one will be cleaned up > when its source package gets superseded. > > To fix that we have a few options: > - Release Wireshark 4.6.2 with Stratoshark version bumped - fixes > everything everywhere. > - Change Stratoshark's version in Debian/Ubuntu to 0.9.3+4.6.1, which > looks a bit strange, but packaging will be fine. Also does not solve > the problem for other distros. > - Ignore the problem for now and start bumping Stratoshark's version > when Wireshark 4.6.2 gets released. > > How should we proceed?
I've fixed the issue in Debian/Ubuntu by bumping the package version, but going forward the Stratoshark version should be bumped with each Wireshark release. Cheers, Balint _______________________________________________ Wireshark-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
