|
Notes |
|
|
(0022634)
|
|
Pol M
|
|
2023-01-04 20:44
|
|
|
|
|
(0022708)
|
|
Zalewa
|
|
2023-01-21 20:15
|
|
|
|
|
(0022709)
|
|
Blzut3
|
|
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. |
|
|
|
(0022710)
|
|
Zalewa
|
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.
|
|
|
|
(0022711)
|
|
Blzut3
|
|
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. |
|
|
|
(0022712)
|
|
Zalewa
|
|
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. |
|
|
|
|
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). |
|
|
|
|
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.
|
|
|
|
(0022715)
|
|
Blzut3
|
|
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.) |
|
|
|
|
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. |
|
|
|
(0022717)
|
|
WubTheCaptain
|
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).
|
|
|
|
|
|
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. |
|
|
|
(0022719)
|
|
WubTheCaptain
|
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)
|
|
|
|
(0022720)
|
|
Blzut3
|
|
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"? |
|
|
|
(0022721)
|
|
WubTheCaptain
|
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.
|
|
|
|
(0022722)
|
|
Zalewa
|
|
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. |
|
|
|
|
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. |
|
|
|
(0022724)
|
|
WubTheCaptain
|
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.
|
|
|
|
(0022733)
|
|
Blzut3
|
|
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? |
|
|
|
(0022737)
|
|
Zalewa
|
|
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. |
|
|
|
(0022739)
|
|
Zalewa
|
|
2023-01-25 18:11
|
|
|
release-checklist-1.4.txt (3,169) 2023-01-04 20:40