davidbannon
commented
1 year ago Hi Jason, thanks for your interest. Its not quite as simple as it may appear. All the betas I have in the 0.36 directory should, in reality, be in a 0.37 directory. But some package managers refuse to install what it thinks are earlier versions than currently installed. See -
dbannon@dell:~$ cat test3.txt
tomboy-ng-setup-0.38+a-2.exeeeeee
tomboy-ng-setup-0.38-a-2.exe
dbannon@dell:~$ cat test3.txt | sort --version-sort
tomboy-ng-setup-0.38+a-2.exeeeeee
tomboy-ng-setup-0.38-a-2.exe
dbannon@dell:~$ cat test3.txt | sort
tomboy-ng-setup-0.38-a-2.exe
tomboy-ng-setup-0.38+a-2.exeeeeeeI think, based on https://www.man7.org/linux/man-pages/man7/deb-version.7.html that debian does a --version-sort. But only with extensive testing can I be sure. RPMs are not well documented, Packman and Apple I have not looked at yet. So, sorry, a blanket commitment to one definition of 'Semantic" is impracticable. Sigh...
Anyway, the situation right now ? The main release page does contain 0.36c releases but just for Linux. With Windows, the bug fixed by 'c' was not applicable. So, the one pointed to by https://github.com/tomboy-notes/tomboy-ng/wiki/Download_Release ('b') is correct. The directory also contains possibly d..g suffix beta releases as noted in the text.
My normal policy is to have just a numeric version on the actual release, however, some late found bugs and a upstream problem caused by Gnome made that difficult with 0.36. The text in the Release Page (not the Download_Release wiki page) defines d..g as being beta releases. The problem is that I release so many different packages now, the list is totally unmanageable. Thats why I have that wiki Download_Release page, its very human readable, generated by a script so easy for me too. But the result is not script able.
As that release directory only ever has one release (for each platform) and every numeric change is reflected in a new release directory, maybe a better approach (for me and you) is needed. How would this affect you (before I start that extensive testing) ?
- I always release only a numeric version number ? So, if I have a small bug fix I need to urgently add to eg 0.37, instead of calling it 0.37a, I will call it 0.38. The down side of this approach might be that sometimes, some platforms may have different release versions available from others.
- Beta (rc, alpha etc) will always be a lower case letter added to the numeric part. So, as at present, a beta release of 0.38 will be called 0.37a.
- Given the above, that 0.37a beta will appear in a release directory called 0.38 but will be marked as containing only betas until Release and then, all betas will be removed. You, as a packager, probably DO NOT want to take those beta 0.37a files even though they may appear more attractive than the 0.37 ones.
Now, to further complicate, the reason there is many betas appearing in 0.36c right now is I am warming up for a release, 0.37, I have an upstream (I think) problem with Debian Bookworm 32bit. If I can solve that, its otherwise ready to go. So, maybe its worth your while waiting a bit ?
If you want to run now, then grab the file https://github.com/tomboy-notes/tomboy-ng/releases/download/v0.36c/tomboy-ng-setup-0.36b.exe - its functionally, on Windows, identical to the 0.36c version on Linux and MacOS.
In terms of Scoop, new to me. I package (for windows) using quite an old version of the packaging tool. Another user has asked me about Windows WinGet and I am aware of the need to upgrade the Windows packaging. For the record, a tomboy-ng install does not write to the registary but does read it to try and determine if user prefers dark mode.
Phew ! Possibly a record length response.
David
jasongodev
Good day authors, I'm one of the volunteers in a project called Scoop, a Windows package manager that allows downloading apps using the command line. We are like Chocolatey or APT.
There's a contributor who wanted to submit Tomboy in our package ecosystem. However we are having problems with your versioning system as it has an inconsistent pattern.
Take for example release version 0.36c. We normally expect that this version will have a file that has a 0.36c in its filename. But yours have 0.36b and 0.36e pattern in the exe file. And your other older releases also have weird letter versioning choices.
I can imagine in Semantic Versioning this could have been 0.0.36-rc3, denoting that your "c" version is a release 3. Then for each environment make it will have something like 0.0.36-rc3.exe for the regular exe file, and maybe 0.0.36-rc3+experimental.exe for exe files with more experimental features/flags turned on.
If we have a consistent versioning pattern, we will be able to index and update our JSON manifest for packaging. We will not guess which of the 0.36b.exe and 0.36e.exe is the real exe file of the 0.36c release.
I reference here my comments about this in the Scoop submission: https://github.com/ScoopInstaller/Extras/pull/12208#discussion_r1398380889