starred/tview

Fork 0

mirror of https://github.com/rivo/tview.git synced 2026-04-27 05:45:49 +03:00

[GH-ISSUE #116] Please tag releases with git tags #88

New issue

Closed

opened 2026-03-04 01:01:50 +03:00 by kerem · 6 comments

kerem commented

2026-03-04 01:01:50 +03:00

Owner

Originally created by @skovtunenko on GitHub (May 12, 2018).
Original GitHub issue: https://github.com/rivo/tview/issues/116

Thank you for a great tui!
Having human-readable change list is great, but can you tag your code with git tags also?
Thanks!

Originally created by @skovtunenko on GitHub (May 12, 2018). Original GitHub issue: https://github.com/rivo/tview/issues/116 Thank you for a great tui! Having human-readable **change list** is great, but can you tag your code with **git tags** also? Thanks!

kerem closed this issue

2026-03-04 01:01:50 +03:00

kerem commented

2026-03-04 01:01:51 +03:00

Author

Owner

@rivo commented on GitHub (May 12, 2018):

How would you use those tags? Why are they needed?

@rivo commented on GitHub (May 12, 2018): How would you use those tags? Why are they needed?

kerem commented

2026-03-04 01:01:51 +03:00

Author

Owner

@skovtunenko commented on GitHub (May 12, 2018):

@rivo , for now this is the simplest way to help with reproducible builds. Go vendoring tools and the most popular tool dep capable to get the sources from specified git tag.
Here is more details about semver tags:
https://golang.github.io/dep/docs/Gopkg.toml.html#version

With every commit, you can break public API and if someone relies on your API, then having tags can help to download some concrete compatible version of your beautiful library.

@skovtunenko commented on GitHub (May 12, 2018): @rivo , for now this is the simplest way to help with reproducible builds. Go vendoring tools and the most popular tool **dep** capable to get the sources from specified **git tag**. Here is more details about semver tags: https://golang.github.io/dep/docs/Gopkg.toml.html#version With every commit, you can break public API and if someone relies on your API, then having tags can help to download some concrete compatible version of your beautiful library.

kerem commented

2026-03-04 01:01:52 +03:00

Author

Owner

@rivo commented on GitHub (May 14, 2018):

I know semver tags and I understand how they are commonly used. Maybe I wasn't very specific with my question. I would like to understand where you specifically had a problem with tview and missing tags.

I have two comments about this:

I try very hard not to break the public API. This goes so far as to even refusing some requests because implementing them would break the API. There have been a few breaks in the beginning of this (five month old) project but newer features/changes should be additions, not breaking changes.
Every commit in this project is either a bugfix or some improvement. By the semver logic, I'd have to add a tag for each commit. I'd like to save myself that effort. (And to be honest, I know I will forget it anyway. The reason I haven't used git tags because I forgot to add them frequently.) I know the revision parameter is frowned upon but it is there so it won't keep you from putting tview into dep.

But I'd like to hear if someone has had problems with backwards compatibility or similar issues. If my workflow is giving you serious problems in your project, we should definitely discuss.

@rivo commented on GitHub (May 14, 2018): I know semver tags and I understand how they are commonly used. Maybe I wasn't very specific with my question. I would like to understand where _you specifically_ had a problem with `tview` and missing tags. I have two comments about this: - I try very hard not to break the public API. This goes so far as to even refusing some requests because implementing them would break the API. There have been a few breaks in the beginning of this (five month old) project but newer features/changes should be additions, not breaking changes. - Every commit in this project is either a bugfix or some improvement. By the semver logic, I'd have to add a tag for each commit. I'd like to save myself that effort. (And to be honest, I know I will forget it anyway. The reason I haven't used git tags because I forgot to add them frequently.) I know [the `revision` parameter](https://golang.github.io/dep/docs/Gopkg.toml.html#revision) is frowned upon but it is there so it won't keep you from putting `tview` into `dep`. But I'd like to hear if someone has had problems with backwards compatibility or similar issues. If my workflow is giving you serious problems in your project, we should definitely discuss.

kerem commented

2026-03-04 01:01:52 +03:00

Author

Owner

@rivo commented on GitHub (May 23, 2018):

Will reopen when there's more information.

@rivo commented on GitHub (May 23, 2018): Will reopen when there's more information.

kerem commented

2026-03-04 01:01:52 +03:00

Author

Owner

@vladimirvivien commented on GitHub (Nov 17, 2018):

Can this be reopen? I appreciate the fact that you work hard to ensure the API is backward compatible. I really like tview's simple and well-designed API.

However, would you consider tagging at least 1 previous version for the following reasons

Go modules (1.11+) encourages tagging/sem-versioning for reproducible builds (in time)
As an adopter of this project, knowing that there are stable snapshots is a good reassurance that builds can be reproduced regardless of what is happening in HEAD.

At the very least, would you consider creating some branches ?

Thank you.

@vladimirvivien commented on GitHub (Nov 17, 2018): Can this be reopen? I appreciate the fact that you work hard to ensure the API is backward compatible. I really like tview's simple and well-designed API. However, would you consider tagging at least 1 previous version for the following reasons - Go modules (1.11+) encourages tagging/sem-versioning for reproducible builds (in time) - As an adopter of this project, knowing that there are stable snapshots is a good reassurance that builds can be reproduced regardless of what is happening in HEAD. At the very least, would you consider creating some branches ? Thank you.

kerem commented

2026-03-04 01:01:52 +03:00

Author

Owner

@rivo commented on GitHub (Nov 19, 2018):

Please have a look at #169. I'm planning to introduce this once modules are official.

@rivo commented on GitHub (Nov 19, 2018): Please have a look at #169. I'm planning to introduce this once modules are official.