search

preservim / tagbar

Vim plugin that displays tags in a window, ordered by scope
https://preservim.github.io/tagbar
Other
6.13k stars 488 forks source link

Last release is 3-year old #617

Closed SkypLabs closed 4 years ago

SkypLabs commented 4 years ago

Hi,

The last release dates back to January 2017 and to date, there are 126 commits to master since this tag.

Have you stopped using Git tags or are you still working on the next release?

Thanks.

alerque commented 4 years ago

What would release do for you? Almost every vim plugin manager I know of these days defaults to installing git HEAD versions of plugins anyway. I could tag releases but at this point they would be almost completely arbitrary. Since we assume the master branch is what most people are using anyway everything that goes there is expected to be in working order. Should I tag every commit? Once a month? There isn't a roadmap for what is being worked on, various people are just fixing bugs or adding features as they need them.

SkypLabs commented 4 years ago

What would release do for you?

Nothing in particular. I was surprised to see releases up to January 2017 and then nothing. I just wanted to clarify the situation.

I could tag releases but at this point they would be almost completely arbitrary.

Thanks but don't bother. As I said, I just wanted to clarify the situation.

Since we assume the master branch is what most people are using anyway everything that goes there is expected to be in working order.

Not everyone uses a clean branching model, sadly. Some people commit untested changes directly into master. Maybe adding a line or two in the installation section of the readme file specifying that master can be used with confidence could be a good idea.

I close this issue as you answered my question. Thanks again.

alerque commented 4 years ago

Maybe adding a line or two in the installation section of the readme file specifying that master can be used with confidence could be a good idea.

I don't know who this would help. As I said all VIM/Neovim plugin managers I know of default to tracking HEAD versions of everything. I know a handful of people deliberately change their configurations to avoid this and hold versions, but those people wouldn't trust the message you suggest anyway. I'm happy to solve problems, but I don't see anything to solve here.

SkypLabs commented 4 years ago

I personally use Vim's native package manager in combination with Git submodules and Dependabot to keep my plugins up to date. Some of them like ALE use releases which is why I tend to look at the branching model of each of my plugins to make sure I use a stable version according to their own development workflow.

In your case, I wasn't sure because you have releases but with the last one being very old.

alerque commented 4 years ago

This project was neglected and fell into a bit of disrepair for quite a while. I took over maintenance of it a while back, but haven't felt the need to add new tags.

If it's all the same to you for your use case I'd suggest tracking master. That's the way must others use this and hence what we cater towards, and I dogfood it that way. If there is a use case for releases I'd be happy to oblige because it's just a matter of picking some tag points, but I'd like to know the use case first. Perhaps for bundling in something like SpaceVim ... but @wsdjeg could speak to whether that is useful better than I could.

wsdjeg commented 4 years ago

I am ok for new release. But I think if there is not any new feature, new release should not be taged. The next release should include:

  1. nvim buffer api, change the buffer context and cursor position without switch windows.

  2. job api

    wsdjeg

    This project was neglected and fell into a bit of disrepair for quite a while. I took over maintenance of it a while back, but haven't felt the need to add new tags.

    If it's all the same to you for your use case I'd suggest tracking master. That's the way must others use this and hence what we cater towards, and I dogfood it that way. If there is a use case for releases I'd be happy to oblige because it's just a matter of picking some tag points, but I'd like to know the use case first. Perhaps for bundling in something like SpaceVim ... but @wsdjeg could speak to whether that is useful better than I could.

    -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/majutsushi/tagbar/issues/617#issuecomment-638003743

alerque commented 4 years ago

Honestly I'd love to see both of those two features. I'm happy to assist anybody that wants to work on them.

That being said I don't think it makes any sense at all to make tagging a release dependent on them. Obviously if those things happened they would be major milestones But if tagging a release for those things makes sense at all then so does tagging for other things as well. If there is any use in having release tags at all, then we should tag now because there are hundreds of big fixes since the last release and if we expect people to stay on tagged releases there is ZERO point in keeping them on a 3 year old release.

The question is not what major new features could we add, but does tagging release at all make sense and actually help anybody. If so we should start tagging at appropriate known-working intervals. If not, then it doesn't really matter what features we do or don't work on, we should keep master in working order at every commit like we do now so that plugin manager that update to it stay usable.

strazto commented 4 years ago

To add to this, I've noticed that your changelog hasn't been changed since your last release, which I view as problematic, because you have added bugfixes and updated support for ctags versions, etc.

To me, these changes would be great candidates for minor version increments, and it'd be nice to see them in a changelog, as it's presently hard to dicern the difference between the tagbar version I'm running vs the head of the repo.

Personally, I don't care about releases (much), but semantic versioning makes it easier to actually understand what makes the head of the repo different from any other commit

alerque commented 4 years ago

@mstr3336 Use git log. Many VIM plugin managers even show you the commit long when updating plugins. At this point if I do anything with the changelog I'm just going to delete it. Without a changelog there is nothing magical about semantic versioning that would make it easier to understand what you have, and I wouldn't be putting anything in the changelog other than a dump of git log.

strazto commented 4 years ago

Point taken, and one of the real reasons I was confused was actually just that I was trying to understand which point of your repo spacevim's tagbar's HEAD pointed at, before I found where it had been added as a static plugin

alerque commented 4 years ago

@mstr3336 You can see above here the author of spacevim actually chimed in here but was against new release tags without major now features. I reasoned after that that what specific features need to get added shouldn't really factor into whether we tag releases or not. If there is a use case for them we should use (appropriately numbered) tags no matter how little or bit the features are. If there is no use case it doesn't really matter what features get added.

I confess I don't really understand how spacevim's release process works or how in manages plugins, but I also didn't hear back about a use case. I'm happy to setup tagged releases if there is a specific use-case for them out there, but so far I am just not seeing one at all for vim plugins. The one big one that comes to mind is if a serious breaking change with no easy upgrade path is introduced then a tag right before that release gives people an easy way to lock down their plugin managers to not upgrade past that. So far that hasn't come up.

alerque commented 3 years ago

For those that may be subscribed to this issue, v3.0.0 has been tagged (see my remarks), but the recommended usage is still to track HEAD.

SkypLabs commented 3 years ago

Thanks @alerque :+1: