search

gokcehan / lf

Terminal file manager
MIT License
7.58k stars 323 forks source link

GoReleaser & Semver for releases? #490

Open coolaj86 opened 3 years ago

coolaj86 commented 3 years ago

SemVer

I've got someone that has requested ( https://github.com/webinstall/webi-installers/issues/149 ) that we add LF to webinstall.dev.

Would you be willing to release this using semver git tags, such as v0.5.0 to make that easier and durable for the future?

GoReleaser

Also, are you familiar with GoReleaser? It makes releasing to github (and other git platforms) completely effortless (and the defaults work probably work perfectly for this project).

I've recently switched to it for some of my projects and I'm loving it. I put a cheat sheet up at https://webinstall.dev/goreleaser. \ The official quickstart is pretty good too. \ I think you'd find it only takes about 10 minutes to get set up.

gokcehan commented 3 years ago

@coolaj86 Thank you for your interest in the project. I would be happy to see lf in webinstall.

SemVer has been suggested a few times before, but I fail to see a good motivation for it. lf is a small simple project with a steady development and a single version number is enough for our needs. SemVer would simply add two unused numbers to our version string. When you say easier and durable, specifically what do you have in mind?

GoReleaser seems like an interesting project, but my experience is that these things tend to be vaporware. For example, there were different tools with similar functionality when I started pushing out releases for lf, but I don't see them around anymore. Our current release setup is already pretty effortless. I simply push a new tag and travis runs our cross build script and uploads binaries to github automatically. I'm not sure what goreleaser would bring to the table.

coolaj86 commented 3 years ago

The case for SemVer

The case for semver is simply to keep to common convention so that things like Webi that use the Github Release API know what to make of the array it gets back from the API - to version is higher or lower than another to get the latest version for a particular platform.

r17 doesn't have any meaning (to a package tool). It may or may not be higher or lower than r1 or r2 or r20. I can write a special version parser just for lf. Not that it's hard - boom, I just did it: parseInt(version.slice(1), 10) - but it's just easier to maintain something when it follows common convention.

Maybe patch versions don't mean anything for your project, in which case I'd say: don't use them. v1.1.0, v1.2.0, v1.175.0, whatever.

But if you decide to change the way a flag or option works at some point in the future, it would be a good signal to someone writing a blog post or tweet or doing a screencast, that v2.x is somehow different than v1.x in a way that causes a behavioral change, and that an article about v1.x may not work perfectly as-is.

The case for GoReleaser

GoReleaser seems to be what most Go projects use and it builds for all platforms simultaneously.

If you've already got something automated that works, great.

I don't have any special affinity for GoReleaser other than that it works well and when you see a project with a .goreleaser.yml you can assume that thing --version will be consistent with git describe --tags and the Github Release API.