Tag and release a version?

[MIvanchev]

Hey, it'd be great for us package maintainers if there was an official version tagged and released. I see the ASD file says 2.0 but there were new commits since then so maybe you can release 2.1?

[avodonosov]

@MIvanchev, hi. What package system you maintain the package for?

[MIvanchev]

I'm about to package for Void Linux in order to release StumpWM (eventually).

[avodonosov]

@MIvanchev, I've changed the version in .asd files to 2.1. Anything else?

I am just not aware how versioning works for VoidLinux and other package managers. Can't the git commit id be used for versioning, as Quicklisp does?

[MIvanchev]

Привет, yes, it'd be great to make a Github release that tags the current commit to 2.1. so no other commit is 2.1.

I am just not aware how versioning works for VoidLinux and other package managers. Can't the git commit id be used for versioning, as Quicklisp does?

It could but there has to be clear understanding that this is a release version aka. something that is usable and not intermediate. Generally most packages use increasing numbers to propagate information in the fashion ...

[avodonosov]

@MIvanchev, for trivial-gray-streams every push to a master branch is a release.

That's fairly typical for common lisp libraries. Look:

$ ls ~/quicklisp/dists/quicklisp/software/

3bmd-20220707-git
alexandria-20220707-git
anaphora-20220220-git
arnesi-20170403-git
babel-20230214-git
bordeaux-threads-v0.8.8
cffi-20230214-git
chipz-20220220-git
chunga-20221106-git
cl-base64-20201016-git
cl-epmd-20140211-git
cleric-20220220-git
cl-erlang-term-20220220-git
cl-fad-20220220-git
closer-mop-20230214-git
cl-ppcre-20220220-git
cl+ssl-20230214-git
collectors-20220220-git
colorize-20230214-git
docparser-20230214-git
drakma-v2.0.9
esrap-20220331-git
flexi-streams-20220220-git
html-encode-1.2
hunchentoot-v1.3.0
ieee-floats-20220220-git
iterate-release-b0f9a9c6-git
md5-20210630-git
monkeylib-binary-data-20111203-git
nibbles-20220331-git
puri-20201016-git
quicklisp-slime-helper-20150709-git
rfc2388-20180831-git
slime-v2.28
split-sequence-v2.0.1
symbol-munger-20220220-git
trivial-backtrace-20230214-git
trivial-features-20211209-git
trivial-garbage-20211230-git
trivial-gray-streams-20210124-git
trivial-types-20120407-git
trivial-with-current-source-form-20211020-git
usocket-0.8.5
zlib-20170403-git

Also, great idea by Quicklisp to use dates instead of commit sha. They are sequential, and formatted such that textual sorting results in ordered dates. And it's more informative than some abstract numbers like 2.1, 2.5.

The date theoretically may be ambiguous, but as long as a package manager does not include two artifacts for the same date (of the same library), it's unique.

Depending on one's taste, he could further disambiguate dates by having a policy that a date means the first commit for that date, or the last commit. Or just add a commit sha after the date.

# generate package artifact name for the last commit, 
# using the committer date and abbreviated hash
$ git log --format=format:trivial-gray-streams-git-%cs-%h  HEAD^..HEAD

trivial-gray-streams-git-2024-02-17-a7ead68

The commit hash is probably an overkill, see yourself.

Quicklisp, I think, uses the date of when it pulls the sources from git, not the commit date.

You can also simply use Quicklisp tarballs and their names, if you don't need to package versions newer than in the latest Quicklisp release.

Is that sufficient for you, given the release policy that any push to master branch is a release?

Not that I avoid the way you suggested because I don't want to help. I just suspect it won't be really useful.

[MIvanchev]

Hey, thanks for taking the time! What is sufficient are up for the reviewers to decide when I submit MRs for packages. The scheme <date>-<commit hash> is not unusual but it's very rare. I think it'll be accepted in this case because you clearly stated what a release is and we could work with that.

QuickLisp's doctrine on the other hand is not entirely correct because some packages in the list are proper versioned (I know because I'm about to release them):

https://gitlab.common-lisp.net/alexandria/alexandria/-/tags
https://github.com/edicl/cl-ppcre/releases

[avodonosov]

@MIvanchev, I hope the <date>-<commit hash> approach works, does it? Can we close the issue for now?

BTW, if your goal is to create a package for StumpWM, do you really need packages for all the dependency CL libraries it uses? Couldn't your StumpWM package build scripts simply use Quicklisp to fetch the dependencies when building StumpWM binary? (As you know, I think, the script can refer specific Quicklisp version, so exactly the same versions of the dependencies would always be downloaded, repeatably).

[MIvanchev]

I hope the - approach works, does it? Can we close the issue for now?

I've actually only used the date, you can check the template here. There's still no guarantee that it'll pass quality inspection by the maintainers. I'm closing the issue ASAP, thank you!

BTW, if your goal is to create a package for StumpWM, do you really need packages for all the dependency CL libraries it uses? Couldn't your StumpWM package build scripts simply use Quicklisp to fetch the dependencies when building StumpWM binary? (As you know, I think, the script can refer specific Quicklisp version, so exactly the same versions of the dependencies would always be downloaded, repeatably).

I was thinking the same thing but IMO the compiled binary still depends on the CL libraries at runtime. They are also included by Arch. It's also not that much about the versions, more about the checksums. We always auto-validate package checksums to make sure a version is not re-released with malware (or just as a bad practice). Ultimately, it's also easier for the user to just use the Void repository for packages.