Hi Gerald, Gerald Combs <ger...@wireshark.org> 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 <ger...@wireshark.org> 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 <ger...@wireshark.org> 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! > > [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? As long as we just increase the versions we should be fine, indeed. Cheers, Balint _______________________________________________ Wireshark-dev mailing list -- wireshark-dev@wireshark.org To unsubscribe send an email to wireshark-dev-le...@wireshark.org
