Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Doomseeker Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004082Doomseeker[All Projects] Epicpublic2023-01-04 20:402023-02-19 14:10
ReporterZalewa 
Assigned ToZalewa 
PriorityhighSeverityfeatureReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version1.3.3 
Target Version1.4.0Fixed in Version1.4.0 
Summary0004082: Doomseeker 1.4 release
DescriptionI've done everything I wanted for Doomseeker 1.4, so I suppose it's time for a release. Just about a year after Doomseeker 1.3.3. The detailed instructions are in the checklist txt attachment.
Additional InformationDoomseeker 1.3.3 release: 0003959
Attached Filestxt file icon release-checklist-1.4.txt [^] (3,169 bytes) 2023-01-04 20:40 [Show Content]
patch file icon 0001-CHANGELOG-Yank-1.4-create-a-new-release-1.4.0.patch [^] (2,082 bytes) 2023-01-24 15:54 [Show Content]
patch file icon v2-0001-CHANGELOG-Yank-1.4-create-a-new-release-1.4.0.patch [^] (2,085 bytes) 2023-01-24 15:58 [Show Content]
patch file icon v3-0001-CHANGELOG-Yank-1.4-create-a-new-release-1.4.0.patch [^] (2,082 bytes) 2023-01-24 16:00 [Show Content]
patch file icon v4-0001-CHANGELOG-Yank-1.4-create-a-new-release-1.4.0.patch [^] (2,083 bytes) 2023-01-24 16:06 [Show Content]

- Relationships

-  Notes
User avatar (0022634)
Pol M (developer)
2023-01-04 20:44

 Let's goooo
User avatar (0022708)
Zalewa (developer)
2023-01-21 20:15
edited on: 2023-01-21 20:15

 Ok, let's do this. Stage 1 completed.

Tag:'https://bitbucket.org/Doomseeker/doomseeker/commits/tag/1.4 [^]'
Website:'https://bitbucket.org/Doomseeker/website/commits/9e78407f2f7bea2c96908b1fdf2fbccfb49c6c1c [^]'

Reassigning to Blzut for stage 2.

Also, I need to add a hint to the checklist to remind myself next time that the libwadseeker src zip can be easily created with the makesourcepackages.sh script because I forgot how this is done again.
User avatar (0022709)
Blzut3 (administrator)
2023-01-21 21:12

 While you can technically generate the src archive, I have the signing key so given that signing is an optional part of that script I'd be regenerating it anyway.
User avatar (0022710)
Zalewa (developer)
2023-01-21 21:40
edited on: 2023-01-21 21:41

 That's right, but we're packaging the libwadseeker source as .tar.xz and as a .zip. The "Wadseeker Development Kit" download on the Windows page gets the .zip archive, while the "Wadseeker Source" download on the Source page gets the .tar.xz. The .sig file is for the .tar.xz only. Also there's no link to the .sig file on the website.

I create the .zip file by creating the .tar.xz first and then repacking it as .zip.
User avatar (0022711)
Blzut3 (administrator)
2023-01-23 05:59

 Files uploaded. Note that since you set VERSION_STRING to 1.4.0 in versiondefs.cmake instead of 1.4, the source package is named 1.4.0. It probably makes sense to just start including the .0 in the other package names anyway. The Mac dmg can simply be renamed without issue if so.
User avatar (0022712)
Zalewa (developer)
2023-01-23 18:04

 The habit of having 3 components in the version number got the better of me. Even though I remembered we're omitting the PATCH component if it's 0, I made the mistake in that one place where it is crucial. Now we have a mishmash. The website, the changelog and the tag are all just "1.4". The components that have "1.4.0" are doomseeker.exe in all binary packages, the tar.gz source package and the auto-update packages.

Since we technically haven't released, yet, I can rewrite the commit and the tag and then redo the parts that have the .0 component.
User avatar (0022713)
WubTheCaptain (reporter)
2023-01-23 20:30

 Lightweight Git tags are temporary, according to git-tag(1). Those lightweight tags have been used in the past for releases (incorrectly).
Nonetheless, I don't like rewriting mistakes (or tags). The beauty of Git is in its history. Please use a new tag (preferably an annotated one).
User avatar (0022714)
WubTheCaptain (reporter)
2023-01-23 20:32
edited on: 2023-01-23 20:32

 In the future to avoid similar issues, I would like to see MAJOR.MINOR.PATCH version numbering (from SemVer) for all the next releases, from this point onward.
User avatar (0022715)
Blzut3 (administrator)
2023-01-24 04:11

 It doesn't seem like anyone has an objection to just not eliding the .0 going forwards, so it would make more sense to me to adjust the documentation accordingly. (1.4 and 1.4.0 are logically equivalent so I'm not sure there's even a need to make further changes besides maybe renaming the tag.)
User avatar (0022716)
WubTheCaptain (reporter)
2023-01-24 14:23

 Commit a new change to CHANGELOG, describe version 1.4 in it as [YANKED] (on the right side of 2023-01-21). Keep the 1.4 tag at d47a53624a9b477c084d132599809bb7d06aed7f.
Create a new CHANGELOG entry for release 1.4.0, using a new date. Say in it to have fixed the version number / serious release issue with 1.4, but otherwise it's the same as 1.4. Make a new Git (annotated) tag for this 1.4.0 version.
Upload 1.4.0 sources to the website, etc.
User avatar (0022717)
WubTheCaptain (reporter)
2023-01-24 14:35
edited on: 2023-01-24 14:47

 The above 0004082:0022716 would keep the history of this bug documented, it helps troubleshoot users/distributors experiencing this release bug. Doing it that way may also help automated tools (i.e. Debian packaging) discover new versions, and I want to avoid a scenario where a packager's source tarball hash checksum would become mismatched or unavailable (i.e. OpenBSD porting) if the tag was simply moved (which would be another bug with the release).
User avatar (0022718)
WubTheCaptain (reporter)
2023-01-24 15:56

 Patch 0001-CHANGELOG-Yank-1.4-create-a-new-release-1.4.0.patch attached. Please apply it, and tag that one with Git object 1.4.0? I've set the release date pre-emptively as tomorrow (2023-01-25) instead of using the "unreleased" thingy, but the release date can be changed as fit.
User avatar (0022719)
WubTheCaptain (reporter)
2023-01-24 16:01
edited on: 2023-01-24 16:06
Quote from WubTheCaptain
Patch 0001-CHANGELOG-Yank-1.4-create-a-new-release-1.4.0.patch attached.

Please see the latest patch instead. (v4-0001-CHANGELOG-Yank-1.4-create-a-new-release-1.4.0.patch)
User avatar (0022720)
Blzut3 (administrator)
2023-01-24 17:36

 OK, if what's effectively a typo in the changelog is going to be a big enough deal to restart the whole release process (vs. just renaming two files and maybe a tag) then so be it. (To be clear, I'm all for updating the Changelog going forward to document the discrepancy, but since we build the commit hash into the binaries moving the tag will necessitate a whole rebuild. So that's why I wanted to either rename or duplicate the tag.)

That said I will note that the Apt repo technically went live, and as you might imagine those have 1.4.0 as their version number. I'm fairly sure Apt will pick up on the repo version being different and offer it as an upgrade but technically this would require a permanent epoch version change.

There are a couple of adjustments I could make to the release scripts based on the previous run (somehow there's always something). Perhaps, since we'll have to rebuild everything anyway, instead of debating the difference between "1.4" and "1.4.0" I can commit those and we'll have a reason to go directly to "1.4.1"?
User avatar (0022721)
WubTheCaptain (reporter)
2023-01-24 17:56
edited on: 2023-01-24 18:12

 To make a note for packagers, the following is the SHA256 hash of the Git tag 1.4 (d47a5367) source with the release issue:
432ec31976d1d513ea2db2de4758c5ef325cf52bb59191470851f4c254f671d2 doomseeker-1.4.0.tar.xz

  • Arch GNU/Linux AUR by Pol_M (I'm assuming) currently uses an explicit Git tag (currently 1.3.3) to select the version. Coincidentally that one is set to skip SHA256 checksum checks, so no breakage yet with that AUR package.
  • Arch GNU/Linux packages could also download a source tarball from an URL and compare its checksum. The $pkgver is an arbitrary Arch version number for the package, and the default one; the Arch package's version number doesn't need to match upstream's (such as pkgver=1.4, _pkgver=1.4.0, source=("https://doomseeker.drdteam.org/files/$pkgname-$_pkgver.tar.xz")). If there's a 1.4.0 PKGBUILD out there somewhere using a source tarball download, if either the filename or checksum changes, this PKGBUILD would break and require changes.
  • OpenBSD distinfo files have the SHA256 + filename, and SIZE + filename to verify a downloaded source tarball; the source tarball will be fetched from ${MASTER_SITES}${DISTNAME}${EXTRACT_SUFX} URL; these three variables are defined in Makefile. DISTNAME=doomseeker-1.4 would fail to download doomseeker-1.4.tar.xz (404 Not Found) I think, but could be hackable by setting EXTRACT_SUFX=.0.tar.xz temporarily for this version. DISTNAME=doomseeker-1.4.0 would currently download doomseeker-1.4.0.tar.xz matching the Git object tag 1.4 (d47a5367) release, with a matching filesize and size; but I anticipate this has another issue with the port's OpenBSD pkg being versioned "1.4.0". If the upstream tarball changes, the port maintainer needs to update the distinfo files when the doomseeker-1.4.0.tar.xz changes at upstream. Alternatively, OpenBSD can also clone a source from Git...
  • Debian scans the Vcs-Browser and Vcs-Git URIs from control with vcswatch, and reports about changes (new Git tags). I am not sure what would happen if the 1.4 tag would be rewritten, but there's a plausibility of not getting notified of new upstream changes at all.
  • debian/watch files point to the source tarball directory index URL with a regex match (such as https://doomseeker.drdteam.org/files/doomseeker-(.*).tar.xz) or a Git repository, to download the package.
  • Usually, Debian maintainers keep a pristine copy of an upstream version branch (1.4), either as a Git branch or as a source tarball. If the 1.4 tag is rewritten to a new commit (after applying a Debian Git branch), I anticipate issues breakage could occur when comparison is made to pristine source branches/tarballs, as a matching pristine source tarball is generally a requirement for distribution.
User avatar (0022722)
Zalewa (developer)
2023-01-24 18:09

 Please give me the chance to respond. I really shouldn't (and sometimes can't) respond during my work time hours.

Quote from Blzut3
It doesn't seem like anyone has an objection to just not eliding the .0 going forwards, so it would make more sense to me to adjust the documentation accordingly. (1.4 and 1.4.0 are logically equivalent so I'm not sure there's even a need to make further changes besides maybe renaming the tag.)

I was about to say that I intend to own the mistake and resolve it with least friction possible. This involves:

1. Renaming the Windows .zip and Mac packages to "1.4.0". The Windows zip doesn't have a top-level directory inside so renaming the file is enough. Similar goes for the Mac package.
2. Leave the changelog as-is and keep the "1.4" tag. The changelog links to the "1.4" tag, so we shouldn't be removing it.
3. For completness, add "1.4.0" tag next to the "1.4" tag, making them equivalent.
4. Adjust the website to offer "1.4.0" instead of "1.4".

Quote from Blzut3
the Apt repo technically went live, and as you might imagine those have 1.4.0 as their version number. I'm fairly sure Apt will pick up on the repo version being different and offer it as an upgrade but technically this would require a permanent epoch version change.

Apt uses version comparison methods that you can test with `dpkg --compare-versions`, and it considers 1.4 to be older than 1.4.0
$ dpkg --compare-versions 1.4 lt 1.4.0 && echo y || echo n
y

So if you replace 1.4.0 in apt with 1.4, it won't offer the replacement for anyone who has already installed 1.4.0.
User avatar (0022723)
WubTheCaptain (reporter)
2023-01-24 19:00
Quote from Zalewa
1. Renaming the Windows .zip and Mac packages to "1.4.0". The Windows zip doesn't have a top-level directory inside so renaming the file is enough. Similar goes for the Mac package.

Winget uses absolute URLs for downloads. Wondering why I didn't see Doomseeker packaged in the Windows Package Manager Community Repository, I later found out Winget only supports MSIX, MSI, APPX or .exe application installers anyway. I don't foresee issues with renaming.
Quote from Zalewa
2. Leave the changelog as-is and keep the "1.4" tag. The changelog links to the "1.4" tag, so we shouldn't be removing it.

I agree, the 1.4 tag should remain to exist. After my longer consideration how various distributions may be affected, the 1.4.0 version number should be documented in the next version's (1.4.1) changelogs at the earliest. The patch I've authored shouldn't be used for the 1.4.0 tag then.
Quote from Zalewa
3. For completness, add "1.4.0" tag next to the "1.4" tag, making them equivalent.
4. Adjust the website to offer "1.4.0" instead of "1.4".
.
Sounds agreeable.
User avatar (0022724)
WubTheCaptain (reporter)
2023-01-24 19:26
edited on: 2023-01-24 19:27
Quote from WubTheCaptain
Quote from Zalewa
1. Renaming the Windows .zip and Mac packages to "1.4.0". The Windows zip doesn't have a top-level directory inside so renaming the file is enough. Similar goes for the Mac package.

[...] I don't foresee issues with renaming.

No changes required for Homebrew formulae (nevermind Homebrew Formulae repository doesn't have Doomseeker available) source builds with this change, but I'm thinking a Homebrew binary download manifest (doomseeker.rb) may need to change a version number from 1.4 to 1.4.0 now. I noticed there's no HTTP redirect from doomseeker-1.4_macosx.dmg to doomseeker-1.4.0_macosx.dmg, so there's currently some breakage for theoretical Homebrew casks/bottles/binary whatever on Mac.
User avatar (0022733)
Blzut3 (administrator)
2023-01-25 04:31
Quote from Zalewa
Apt uses version comparison methods that you can test with `dpkg --compare-versions`, and it considers 1.4 to be older than 1.4.0

Actually ran that test today as well, was slightly surprised by that but it makes sense based on how the algorithm works. FYI, rpm does the same.

Anyway, your proposed changes are essentially what I proposed so not sure if you need anything more from me?
User avatar (0022737)
Zalewa (developer)
2023-01-25 07:22
Quote from Blzut3
not sure if you need anything more from me?

Only your confirmation. Which I just received, thanks.

I progressed with the release and all things should be up: the website and the auto-update on the stable channel. I will have to do the announcements later today.
User avatar (0022739)
Zalewa (developer)
2023-01-25 18:11

 And here's the announcement:'https://zandronum.com/forum/viewtopic.php?f=8&t=10887 [^]'

It's done. Thanks to all who contributed and persevered through all of this.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2023-01-04 20:40 Zalewa New Issue
2023-01-04 20:40 Zalewa File Added: release-checklist-1.4.txt
2023-01-04 20:44 Pol M Note Added: 0022634
2023-01-21 08:35 Zalewa Assigned To => Zalewa
2023-01-21 08:35 Zalewa Status new => assigned
2023-01-21 20:13 Zalewa Assigned To Zalewa => Blzut3
2023-01-21 20:15 Zalewa Note Added: 0022708
2023-01-21 20:15 Zalewa Note Edited: 0022708 View Revisions
2023-01-21 21:12 Blzut3 Note Added: 0022709
2023-01-21 21:40 Zalewa Note Added: 0022710
2023-01-21 21:41 Zalewa Note Edited: 0022710 View Revisions
2023-01-23 05:59 Blzut3 Note Added: 0022711
2023-01-23 05:59 Blzut3 Assigned To Blzut3 => Zalewa
2023-01-23 18:04 Zalewa Note Added: 0022712
2023-01-23 18:05 Zalewa Assigned To Zalewa => Blzut3
2023-01-23 18:05 Zalewa Status assigned => feedback
2023-01-23 20:30 WubTheCaptain Note Added: 0022713
2023-01-23 20:32 WubTheCaptain Note Added: 0022714
2023-01-23 20:32 WubTheCaptain Note Edited: 0022714 View Revisions
2023-01-24 04:11 Blzut3 Note Added: 0022715
2023-01-24 14:23 WubTheCaptain Note Added: 0022716
2023-01-24 14:35 WubTheCaptain Note Added: 0022717
2023-01-24 14:42 WubTheCaptain Note Edited: 0022717 View Revisions
2023-01-24 14:43 WubTheCaptain Note Edited: 0022717 View Revisions
2023-01-24 14:47 WubTheCaptain Note Edited: 0022717 View Revisions
2023-01-24 15:54 WubTheCaptain File Added: 0001-CHANGELOG-Yank-1.4-create-a-new-release-1.4.0.patch
2023-01-24 15:56 WubTheCaptain Note Added: 0022718
2023-01-24 15:58 WubTheCaptain File Added: v2-0001-CHANGELOG-Yank-1.4-create-a-new-release-1.4.0.patch
2023-01-24 16:00 WubTheCaptain File Added: v3-0001-CHANGELOG-Yank-1.4-create-a-new-release-1.4.0.patch
2023-01-24 16:01 WubTheCaptain Note Added: 0022719
2023-01-24 16:06 WubTheCaptain File Added: v4-0001-CHANGELOG-Yank-1.4-create-a-new-release-1.4.0.patch
2023-01-24 16:06 WubTheCaptain Note Edited: 0022719 View Revisions
2023-01-24 17:36 Blzut3 Note Added: 0022720
2023-01-24 17:43 Zalewa Assigned To Blzut3 => Zalewa
2023-01-24 17:43 Zalewa Status feedback => assigned
2023-01-24 17:56 WubTheCaptain Note Added: 0022721
2023-01-24 17:56 WubTheCaptain Note Edited: 0022721 View Revisions
2023-01-24 18:01 WubTheCaptain Note Edited: 0022721 View Revisions
2023-01-24 18:01 WubTheCaptain Note Edited: 0022721 View Revisions
2023-01-24 18:03 WubTheCaptain Note Edited: 0022721 View Revisions
2023-01-24 18:03 WubTheCaptain Note Edited: 0022721 View Revisions
2023-01-24 18:09 Zalewa Note Added: 0022722
2023-01-24 18:12 WubTheCaptain Note Edited: 0022721 View Revisions
2023-01-24 19:00 WubTheCaptain Note Added: 0022723
2023-01-24 19:15 Zalewa Assigned To Zalewa => Blzut3
2023-01-24 19:15 Zalewa Status assigned => feedback
2023-01-24 19:26 WubTheCaptain Note Added: 0022724
2023-01-24 19:26 WubTheCaptain Note Edited: 0022724 View Revisions
2023-01-24 19:27 WubTheCaptain Note Edited: 0022724 View Revisions
2023-01-25 04:31 Blzut3 Note Added: 0022733
2023-01-25 07:07 Zalewa Assigned To Blzut3 => Zalewa
2023-01-25 07:07 Zalewa Status feedback => assigned
2023-01-25 07:22 Zalewa Note Added: 0022737
2023-01-25 18:11 Zalewa Note Added: 0022739
2023-01-25 18:11 Zalewa Status assigned => needs review
2023-02-19 14:10 Zalewa Status needs review => resolved
2023-02-19 14:10 Zalewa Fixed in Version => 1.4.0
2023-02-19 14:10 Zalewa Resolution open => fixed




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker