[Gerald Combs <gerald@xxxxxxxxxxxxx>]

On 1/7/25 6:20 AM, Bálint Réczey wrote:
> Hi Gerald,
>
> Gerald Combs <gerald@xxxxxxxxxxxxx> 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 <gerald@xxxxxxxxxxxxx> 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

[1] Sun similarly bumped Solaris from 2.6 to 7 and Java from 1.4 to 5. Nothing bad ever happened to them, so we should be perfectly fine, right?