search

rivo / tview

Terminal UI library with rich, interactive widgets — written in Golang
MIT License
11.12k stars 576 forks source link

Build Semantic Versioning Releases #788

Open Klaus-Tockloth opened 1 year ago

Klaus-Tockloth commented 1 year ago

For better use in production it would be helpful if the tview project builds releases according to Semantic Versioning. Something like "v1.2.3".

rivo commented 1 year ago

This has been discussed at length before. See #442. Also, from the main README:

I try really hard to keep this project backwards compatible. Your software should not break when you upgrade tview.

Klaus-Tockloth commented 1 year ago

The advantage of semantic versioning for me is that it has semantic (major.minor.fix).

Semantic Versioning versus your pattern: v1.2.0 versus v0.0.0-20221128165837-db36428c92d9 v1.2.1 versus v0.0.0-20230104153304-892d1a2eb0da

rivo commented 1 year ago

That's circular reasoning. The question is, why do you need semantic versioning? Describe a situation where you have problems if it's not semantic versioning.

mih-kopylov commented 1 year ago

@rivo I'm also interested in semantic versions.

And here's one of the reasons why. Github's dependabot provides a convenient and automatic way of bumping dependencies and making sure they're up to date. The way it does it, it loads https://proxy.golang.org:443/github.com/rivo/tview/@v/list which is empty since there're no releases yet, and therefore doesn't found anything it can switch the dependency to. So Dependabot won't update the tview automatically without releases.

The other reason is just to follow convenient best practices that community got used to :) I would really appreciate if tview has releases with changelog!

SamWhited commented 1 year ago

We have the same issue with several tools we use (they expect a release tag and don't support the fake version format). Technically this is a problem with those tools, but it would still be much nicer and we'd have to jump through fewer hoops if there were a v0.0.1 release or something. It's bitten us a number of times in a number of different ways at this point.

SamWhited commented 1 year ago

A quick follow up to my earlier comment because I just ran into another issue that would at least partially be solved by using semver correctly:

I just went to build a project and needed a slightly newer feature of tview. I updated, but it pulled in a breaking change to one of the interfaces, breaking my build. If the project had been using semver I could have updated to the latest version that was still minor-version compatible. Of course, mistakes could still be made, but at least I'd have an easy way to try out different versions instead of having to go dig around and find commit IDs.

I'm still really sorry to see tview not using version numbers, it looks bad in my go.mod file (not that this matters, really) and has caused me a lot of grief with tooling. I know you don't like it, but your users will thank you.

lukaszraczylo commented 1 year ago

Hi everyone, I'm a big fan of the project, and please do not take it as an advertisement - but for the build process itself, feel free to use the semver generator ( also available as a github action to make it easier ) - https://github.com/lukaszraczylo/semver-generator It will generate the new semantic version using config ( minor and major ) and commits ( for patch versions ), removing the headache of bumping the versions :)

rivo commented 10 months ago

I updated, but it pulled in a breaking change to one of the interfaces, breaking my build.

@SamWhited I would like to know what that was. A newer tview version should not break anything (subject to some minor exceptions listed in the README).

If someone has a suggestion on how to set up GitHub so it automatically version-tags every commit with an increasing patch number, that would be helpful.

SamWhited commented 2 months ago

Sorry, missed this comment but I Just showed up to comment again so I can at least answer it this time: I just went to upgrade and a bunch of my structs no longer implement tview.Primitive because the PasteHandler method was added at some point (among other things, I have a rather long list of errors when I try to build with the newest version).

Please don't just automatically add patch numbers, just tag a release when one is needed, not every single time, otherwise we'll just wind up with a breaking change in a minor patch version and it won't actually help solve this problem.

At this point I am outright on my knees begging, please add a version number. This is still a frequent source of problems in my project, and it's pretty easy to do a git tag v0.0.whatever on occasion and especially when making a breaking change.