Release Strategy

[tjdevries]

My Proposal for a release strategy for telescope, until we are ready to release actual "versions" of telescope (such as 0.1.0 which have a defined set of neovim versions that they support).

We cut tags related to upstream Neovim versions:
tag: nvim-0.6.1 (this gets tagged when nvim released 0.6.1)
tag: nvim-0.7.0 (this gets tagged when nvim released 0.7.0)

Eventually, we move to cutting our own tags (and perhaps specifying the neovim version via plugin specs)
tag: 0.1.0 (say what versions are supported)
tag: 0.2.0 (say what versions are supported)
tag: ...

We have two branches (but all development happens on `master`)
branch: nvim-stable (this gets updated with whatever the latest nvim-0.X version is released)
branch: master (this gets updated with whatever we want to try and use nvim nightly)

" Users can do this if they plan to update whenever neovim releases a new stable version
Plug 'nvim-telescope/telescope.nvim', branch = 'nvim-stable'

" Users can do this if they want to stay on a particular nvim version
Plug 'nvim-telescope/telescope.nvim', tag = 'nvim-0.6.1'

" Users can do this if they work on nightly
Plug 'nvim-telescope/telescope.nvim'

[tjdevries]

cc @clason @mjlbach (if you wanna chat about) @Conni2461 (when you're done with exams) cc anyone else who wants to chat about it.

[clason]

Will bugfixes be backported to nvim-stable?

[tjdevries]

No, nothing is ever backported

[clason]

Then I'm not sure you need a separate branch.

[tjdevries]

So the reason for nvim-stable is that it gets updated when we release a new tag (so nvim-stable will point to nvim-0.6.1 for now, but then move to nvim-0.7.0 when it's released). So this means users who just upgrade only when we have a release don't have to change their config Plug. I'm happy to do less though :)

[clason]

Yeah, but can't you do the same with a tag? (nvim-stable that points to the same revision as nvim-0.whatever?) I think that's exactly what Neovim is doing.

My argument against a branch is that it carries the (weak) implicit promise that it will be updated.

[tjdevries]

sure, we can do a tag instead, some people don't like using tags mutably though :)

[tjdevries]

(I do not care, I just want to use nightly features and not have anyone worry about doing different versions)

[clason]

sure, we can do a tag instead, some people don't like using tags mutably though :)

Those people wouldn't be using Neovim, then ;)

I assume you will follow the same release strategy for plenary?

[tjdevries]

Yeah, that seems fine with me

[Conni2461]

My exams are over and i finally have a month of free time. So I will most likely try to work 2 days per week on telescope + org and plenary.
I thought about the release strategy again and i think i am down for it. I could prepare everything in the next couple of days and i wouldn't wait for PR x / y / z because otherwise we never do it, like the 0.1 release (my bad) 🤣

[davvid]

@clason git fetch and git fetch --tags will not clobber existing tags. Here's an example of what git reports in a repo that already has a v0.0.1 tag. I deleted it locally and created a new tag with the same name to see what happens when I try to fetch the server's tags:

$ git tag -d v0.0.1             # delete the existing one
$ git tag -m msg v0.0.1         # create a new tag with the same name

$ git fetch --tags              # fetch tags from the server
From ...
 ! [rejected]        v0.0.1     -> v0.0.1  (would clobber existing tag)

You have to force while fetching, which is a bad idea in general.

$ git fetch -f --tags
From ...
 t [tag update]      v0.0.1     -> v0.0.1

For that reason it's probably best to use a branch, which is something that's expected to move forward over time.

[Conni2461]

With #1938 i dont think we need this anymore

It will bring a 0.1.0 tag and probably a 0.1-release branch for long term support.

IMO currently there is no need for bumping the minimum neovim version to nightly. I'd like to close this

CC @tjdevries

[Conni2461]

I think we could consider moving the master branch to track nightly after the initial release but this will only work if users actually switch to 0.1.0 tag or 0.1-release release branch

None the less, i will be the one that currently maintains the project so i will just pick what works for me best which is the method described above. I will communicate this on the release date.

Closing as this discussion is in my opinion resolved