Add a `stable` branch (and optionally make it default)

nvim-neorg / neorg

Modernity meets insane extensibility. The future of organizing your life in Neovim.

GNU General Public License v3.0

6.51k stars 214 forks source link

Add a `stable` branch (and optionally make it default) #1384

Open champignoom opened 7 months ago

champignoom commented 7 months ago

Issues

[X] I have checked existing issues and there are no existing ones with the same request.

Feature description

The whole luarocks system since v8.0 seems to be not stable enough yet, see for example https://github.com/nvim-neorg/neorg/issues/1351.

A kickstart config that takes care of all the glitches also seems to be still on the way, see https://github.com/nvim-neorg/neorg/issues/1366.

Until then, I suggest to add a more visible and more fool-proof stable branch. For example:

Make a stable branch from a pre-v8 working commit, like https://github.com/nvim-neorg/neorg/commit/086891d396ac9fccd91faf1520f563b6eb9eb942, and optionally make it default;
Add a pointer like "see stable version here" in main/README;
Add something like commit = "086891d396ac9fccd91faf1520f563b6eb9eb942", in the TLDR section of stable/README

Help

Implementation help

No response

vhyrro commented 7 months ago

I think switching the default branch is a bad idea but adding an entry about 7.0.0 sounds good! I'll do that soon

champignoom commented 7 months ago

@vhyrro I just made a few changes, since v7.0.0 itself has some highlighting issues with modern treesitter and kanagawa.

pysan3 commented 7 months ago

I'm actually against this. External modules will need to test to work with two versions of neorg which is pretty difficult sometimes.

max397574 commented 7 months ago

well if we've somewhen fixed the luarocks things there hopefully should never be so many big issues again

champignoom commented 7 months ago

well if we've somewhen fixed the luarocks things there hopefully should never be so many big issues again

Maybe, but the main point is about a notion of "stable branch", which would still help when (or especially when) a good package manager is ready.

The new actions should boil down to:

pointing to the stable branch from main/README, be it an actual new branch or an existing tag like "v7.0.0"
somehow constantly backporting bug fixes into the stable branch (instead of all the "v?.?.?" tags)

max397574 commented 7 months ago

somehow constantly backporting bug fixes into the stable branch have fun with git constantly picking commits from one branch to another

(instead of all the "v?.?.?" tags) that's the whole point of semver which we decided to use

pysan3 commented 7 months ago

@champignoom

From what I observe, people that cannot install luarocks.nvim are either having skill issues :kek: or are on termux.

The one you linked above is an issue with rocks.nvim and nvim-treesitter not being able to package a rock correctly. This has nothing to do with neorg afaik. Explained very well in https://github.com/nvim-neorg/neorg/issues/1351#issuecomment-2021708858

max397574 commented 7 months ago

having skill issues

Actually in 99% it's skill issue or just doing like 3 things with e.g. Lazy build xyz and things are fixed

vhyrro commented 7 months ago

One thing that isn't a skill issue though is lazy sometimes not running the build script, which I've tried tracking down in the code but the code seems to be behaving just fine...

If we can track down that one problem then we can guarantee that luarocks installation will be correct under 95% of cases (with the remaining 5% being windows users :p). I like the notion that's presented here, but I think it's not the correct call.

Users are enouraged to stay on 7.0.0 if they don't feel like 8.0.0 is giving them the stable experience. The stable tag would only point to 7.0.0 at best, after which it becomes frankly useless once luarocks support is properly stabilized, leaving me to manually update the stable release every time release-please issues a new release tag. So many plugins that initially tried to have a stable branch decided to screw it and move to a release model like ours instead, including neorg several years ago when we had both a dev and a stable branch. I'll add the mention to the README about 7.0.0 right now :)

champignoom commented 7 months ago

From what I observe, people that cannot install luarocks.nvim are either having skill issues :kek: or are on termux.

The one you linked above is an issue with rocks.nvim and nvim-treesitter not being able to package a rock correctly. This has nothing to do with neorg afaik.

@pysan3 That's an issue within dependencies that neorg chooses to depend on. Leaving it to possibly non-dev users to solve is a sign of leaky abstraction. Neorg could have been able to just work, with no excuses.

The stable tag would only point to 7.0.0 at best, after which it becomes frankly useless once luarocks support is properly stabilized, leaving me to manually update the stable release every time release-please issues a new release tag.

@vhyrro I agree that luarocks would potentially make a fundamental difference and solve the mess of versioning altogether. But until it's stablized, or until a tutorial of stably working with an unstable luarock is ready, tags like 8.x.y-alpha could be more informative.