search

pop-os / gtk-theme

System76 Pop GTK+ Theme
GNU General Public License v3.0
780 stars 80 forks source link

Please tag releases #594

Closed alucryd closed 1 year ago

alucryd commented 1 year ago

Hi guys, arch linux use tags to bump its package, could you please add a tag for 8392965608cf2c340fa88cbca132ce7ddb8e352e and future releases?

jacobgkau commented 1 year ago

Every commit to the master branch is essentially a release for Pop!_OS. (They are not actually released in Pop!_OS until they're included in a PR within https://github.com/pop-os/repo-release, but updates are only withheld there for more than a few days in special circumstances.)

The most recent "stable release" on GitHub is currently from late 2020 and the most recent "pre-release" on GitHub is currently from 2021, so it probably wouldn't hurt to tag a new one, even if it's arbitrary. While there is a -git AUR package that would more closely match the Pop!_OS development style, it looks like Arch has a binary package in their community repo that's currently what's out-of-date since it only follows GitHub releases.

I wonder if it would be possible for the Arch maintainer for this package to use the version number in the repo-release repository instead of the one in the GitHub tags, since that's what we use for Pop!_OS releases. (The current version number would be 5.5.1~1659710972~22.04~7ba5da8; the part after the first tilde is a timestamp, so it goes up with each release.)

jacobgkau commented 1 year ago

I tried making a tag myself, but I don't seem to have the proper permissions. @isantop can probably do it. (I'm also not sure why we started putting v at the front of the tag names only at version 5.3.1, but I was going to match the most recent tag with the letter.)

isantop commented 1 year ago

I tagged the most current release as v5.5.1.

The note Jacob brought up about releases is valid; every commit to master in this repository is a new version built and distributed to users.

alucryd commented 1 year ago

@jacobgkau I am said arch maintainer!

Thanks for the tag and explanation. Deriving the version from another repository will be a bit too convoluted compared to our usual workflow. Also arch tends to prefer packaging tags instead of arbitrary commits whenever possible, but exceptions can be made, and I have certainly done so already. In both cases though our package versions are derived from git describe --tags, usually in the form of <latest_tag>.r<commits_since_tag>.<commit_hash> when commits are targeted, so we'd need up to date tags either way.

I will start packaging commits since they are considered stable enough, but if that's not too much trouble it would be great if you could keep tagging every new version from now on. If not I'll devise an appropriate version scheme that doesn't break our vercmp. Thanks!