| 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: wsvx.y.z / ssvx.y.z - RC tags: wsvx.y.zrcn / ssvx.y.zrcn
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.
Unless there are any objections I'll add the ssv0.9.0rc0 tag next Monday.
|