mirror of
https://github.com/rivo/tview.git
synced 2026-04-26 21:35:54 +03:00
[GH-ISSUE #442] please publish a release #316
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tview#316
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jossef on GitHub (May 4, 2020).
Original GitHub issue: https://github.com/rivo/tview/issues/442
It's crucial for some (including me) to freeze their dependencies.
I have my way around by running
still, please publish a release
https://github.com/rivo/tview/releases
@adg commented on GitHub (May 5, 2020):
Doing so would make literally no difference except for the string that appears in your
go.modfile. Why push the maintainer into doing this?@rivo commented on GitHub (May 7, 2020):
People have asked for semver-style tags and I'm thinking about introducing them. But I'm not yet clear on how they would map to my commits. Every commit in this repo is either a bugfix or a new feature. (What else could it be?) Does this mean every commit gets its own tag? If so, that doesn't make much sense to me and it creates unnecessary work on my side.
If only some commits get tags, which ones do and which ones don't? What are common policies for tags?
If someone here can provide some guidance and explain how it benefits the users of this package, it would be helpful to make a decision.
Regarding releases, I have to agree with @adg. Maybe I don't really understand releases completely (at least in the context of a Go package like
tview) but there is no packaged software, no binaries, and I don't have time to write release notes. So it's unlikely that I will introduce releases.@adg commented on GitHub (May 7, 2020):
At the moment every time you push a new commit the Go tool uses a 'pseudo-version' semver string like
v0.0.0-20200414130344-8e06c826b3a5to refer to that specific commit. These are valid semver tags that monotonically increase, so if you want your users to live at HEAD then don't change anything.If, by tagging commits, all you'd be doing is tagging v0.0.1, v0.0.2, etc, with no intention of supporting any particular major/minor release in the long term, then there's no point in introducing tags.
In fact, if you did introduce a tag and then failed to tag subsequent versions, new users of tview would get the most recently tagged version instead of what's at HEAD, which with your current dev process seems like the wrong thing.
@jossef commented on GitHub (May 12, 2020):
Adding my 2 cents here,
I recommend using https://github.com/semantic-release/semantic-release
semantic-releaseis adopted by my team as our last CI pipeline step. All git tags are created automatically based on our commit messagesFor instance, If you will use this form of commit messages convention:
then, when
semantic-releaseexecutes (you can set it up via github actions for all commits in master), it will parse the commit message(s) and will promote the version from (let's say)v1.0.0tov1.0.1according to the changes you have pushedFrom
semantic-releasedocs:@abitrolly commented on GitHub (Jun 5, 2020):
@jossef if it is only for your team, then your team should adopt @rivo :D
@jossef commented on GitHub (Jun 6, 2020):
not only :)
I can help and publish a PR with github actions flow
@rivo - WDYT?
@rivo commented on GitHub (Jun 10, 2020):
I agree with @adg here. The idea is to keep users of the package at HEAD. It's always the most up to date and (hopefully) bug free version. Longer term developments are done in separate branches anyway so HEAD of
mastershould never be in an intermediate/inconsistent state. (I say "should" because mistakes may happen.)All in all, given this procedure, I still haven't seen a good reason to introduce version tags. @jossef's suggestion would simply result in a reformatting of the automatically generated version numbers. I don't see the point.
But again, I'm still open for any good arguments. Specifically, if you can describe why the current handling is problematic to you, I'm all ears.
@ghostsquad commented on GitHub (Jun 13, 2020):
I agree that it's likely just more overhead. However... there are some pros to doing releases:
Autogeneration of release notes & changelog can make it easier for folks to see/understand what's new
Marking releases as "pre-release" and thus potentially saving some folks from downloading a broken version, but allowing folks to "opt-in" to the bleeding edge, knowing that new features might not totally work correctly (or whatever else)
Tags are generally the "human readable" variant of versions. So that it's easier to tell how out of date you are or whatever when looking at
v0.1andv0.2instead ofcb1e5d6and8ca14bbUnderstandably, these are minor. But with a little bit of automation and maybe some enforcement of using https://www.conventionalcommits.org/en/v1.0.0/#summary and https://chris.beams.io/posts/git-commit/ you could greatly improve the release documentation for users.
@ghostsquad commented on GitHub (Jun 13, 2020):
along the lines of
#1above, writing new features only for them to not be discoverable sounds like a terrible waste of time 😉@abitrolly commented on GitHub (Jun 16, 2020):
@ghostsquad can you submit release notes and changelog in PR using hashes and dates to see how it should look like?
@ghostsquad commented on GitHub (Jun 16, 2020):
Like @jossef I would use semantic release. I'm a maintainer of go-jira, and that's how I do releases there.
https://github.com/andygrunwald/go-jira/releases
@ghostsquad commented on GitHub (Jun 16, 2020):
I misspoke. I use "standard-version" for releasing
https://github.com/andygrunwald/go-jira/blob/master/README.md#releasing
@abitrolly commented on GitHub (Jun 16, 2020):
@ghostsquad I don't see that changelog is autogenerated.
@ghostsquad commented on GitHub (Jun 16, 2020):
@abitrolly what do you consider as "autogenerated"? I run a command
standard-version, which looks at the git history and generates the changelog.standard-versiondoes not currently create a Github Release, but that would be a fairly simple addition.@abitrolly commented on GitHub (Jul 12, 2020):
@ghostsquad "autogenerated" means "generated automatically", which means "not manually".
@rivo commented on GitHub (Jul 12, 2020):
@ghostsquad Re (1):
gives you this:
That's your automatically generated changelog.
Re (2): As mentioned before, there is no "release". So there is also no "pre-release". The master branch should never be in a broken state (apart from bugs I don't know about). Any intermediate state during the development of a larger feature will happen in a different branch.
Re (3): Agreed, it's easier. But as I mentioned multiple times, there should be no reason to stay on an older release. I'm trying to keep
tviewbackwards compatible. I'm actually following the recommendation of the Go team here. They even wrote a blog post about this recently.I still don't see where any of this is causing actual problems.
@ghostsquad commented on GitHub (Jul 12, 2020):
I don't see any problems, so I'm bowing out of the conversation.
@rivo commented on GitHub (Jul 12, 2020):
Ok, I'll keep this open for a while in case somebody wants to chime in.