Add tag for Lemmy 0.19.2

[linux-cultist]

Deploying the main version gets us 0.19.2 of Lemmy but just needs a tag added here in the repo as well.

[Nothing4You]

0.19.3 at this point

[Nothing4You]

the tags are there (now, not sure about before), but they're not promoted to github releases

[codyro]

I believe he's referring to the 1.3.1 tag. It got tagged before the VERSION file got bumped to the latest release, so it's behind.

@ticoombs can you retroactively include/update that in the tagged release? What is the best way to handle this? IIRC, it got bumped a day or two after 1.3.1. In that case would we do 1.3.2 anyway?

[dessalines]

Side point, but that VERSION file gets bumped when we do a release: https://github.com/LemmyNet/lemmy/blob/main/scripts/release.sh#L24

Is that the right way to handle it, or should I be doing it differently since we do tagged releases here?

[linux-cultist]

I think every time you update the VERSION, it should be followed by a new tag also. So 1.3.1 in this repo would be VERSION 0.19.1 of Lemmy, 1.3.2 would be VERSION 0.19.2 and so on.

Then it's possible to easily go back to previous version (unless there has been database upgrades between versions, which should be highlighted in the release notes).

[ticoombs]

Is that the right way to handle it, or should I be doing it differently since we do tagged releases here?

Updating the VERSION file is fine, but creating the TAG is what causes the problem when people run git checkout $(git describe --tags). As this only gets the latest TAG.

The reasoning behind the 1.x vs 0.x tagging is because we (lemmy-ansible) also have to include upgrade notes and we didn't want to re-push versions, and the lemmy versions don't make sense when a system also contains ~4 other applications.

If you could not automatically create the tag @dessalines for lemmy-ansible that would solve the confusion.

<3

---

@ticoombs can you retroactively include/update that in the tagged release? What is the best way to handle this? IIRC, it got bumped a day or two after 1.3.1. In that case would we do 1.3.2 anyway?

@codyro You don't retroactively update the tags/versions, you push a new one. You are correct if the VERSION gets updated we need to also push a new tag/release.
The process is to:

• create PR & get it merged with the new release notes / upgrade notes
• git checkout origin main && git tag $version && git push origin $version
• go into github releases, select the new $version, select the old $version, click generate release notes
• edit release notes, if there is something extra. Select Publish release

[dessalines]

I really appreciate yalls help in handling these releases.

[ticoombs]

@dessalines Is it possible to not tag the new releases for lemmy-ansible? That will avoid future issues & clashes with the tags/releases.

Updating main would be perfect & if I am reading the release.sh script correctly, skipping line 29 & 30 should be all the changes that is needed. That way lemmy-ansible still gets updated inline with the new Lemmy versions, while also allowing us to schedule our own releases/tags.

Thanks.

[dessalines]

Sure, I'll remove that part from our lemmy deploy script now.