to echo what i said on discord in a single comment:
since this is coming up, this is semi ironic at least and dumb at most. lite xl's method of configuration is literally via its lua api/modules. you might see mod version as a good solution to safeguard users and plugins with differing version requirements/compatibility but this makes the actual user configured side, the user module, left open.

mod version would work if lite xl wasn't configured in lua and instead a text config or something similar; that's when you'd have a separate plugin api version and program version, since the user side doesn't change when the plugin version does.
that is why the program itself should use semver instead of a specific segment for plugins. it makes it obvious that there is a breaking change. it also entirely avoids having to support multiple versions with lite xl itself (#952), since litepresence should work on both 2.0 and 2.1 but i have to use branches with a different mod version to do that which is an unneeded pain in the ass

you @Guldoman specifically said that browsers do have a separate program version and extension version, but they satisfies the fact that chrome (as an example) is not configured with js and its api and instead a settings page :)

same thing for sublime text (which i'm not even sure has this in the first place)
neovim uses semver. why can't we follow? (in reality this specifically it doesn't matter since it's still pre 1.0)

this is ironic at least and dumb at most.

You've been doing this on Discord too. Don't.

lite xl's method of configuration is literally via its lua api/modules.

Most users don't add complex API-dependent things to their user module, but just configure plugin settings and editor settings directly (which we avoid breaking). Even if we end up having to change something users usually touch, we'll support the old way for a few versions and alert the user that what they're touching has been deprecated.

that is why the program itself should use semver instead of a specific segment for plugins. it makes it obvious that there is a breaking change.

The problem with this approach can be seen for example with big UX changes: the GUI could get a complete overhaul, but the API could change very little or not at all (so it would require a simple patch version bump).

Having the versions separated, avoids useless mod-version bumps and avoids locking the editor version when a big change occurs.

For example let's say we add a new tokenizer (fully compatible with the old one), HiDPI scaling support, file open dialogs and redesign the interface.
All of this can be done by keeping the same mod-version, but just changing the editor version (in this case we would bump the editor version of at least a minor version).
With the combined approach that you suggest we can only bump the patch version (because no breaking API change happened), so a user will not know that major UX changes happened.

it also entirely avoids having to support multiple versions with lite xl itself (#952), since litepresence should work on both 2.0 and 2.1 but i have to use branches with a different mod version to do that which is an unneeded pain in the ass

A combined version approach wouldn't help in this case. We did breaking changes and we didn't keep compatibility with the old version (a major version bump is needed), so your plugin would still be rejected on load.

you @Guldoman specifically said that browsers do have a separate program version and extension version, but they satisfies the fact that chrome (as an example) is not configured with js and its api and instead a settings page :)

Chrome extensions can absolutely change browser settings https://support.google.com/chrome_webstore/answer/6029416?hl=en

same thing for sublime text (which i'm not even sure has this in the first place) neovim uses semver. why can't we follow? (in reality this specifically it doesn't matter since it's still pre 1.0)

That's the approach they decided to take. We decided on a different approach. This PR simply extends how the mod-version works and formally forces us to keep compatibility with minor and patch bumps.

You've been doing this on Discord too. Don't.

:^(

Most users don't add complex API-dependent things to their user module, but just configure plugin settings and editor settings directly (which we avoid breaking). Even if we end up having to change something users usually touch, we'll support the old way for a few versions and alert the user that what they're touching has been deprecated.

statusview is a very good example of a simple thing which has changed in 2.1

With the combined approach that you suggest we can only bump the patch version (because no breaking API change happened), so a user will not know that major UX changes happened.

that would bump the minor version in semver, because it is indeed not a breaking api change, and adds new features.

this is the only actual good argument to me that the separate versions would be wanted, but i guess that means apps shouldnt use semver at all?

Chrome extensions can absolutely change browser settings https://support.google.com/chrome_webstore/answer/6029416?hl=en

that wasnt the point. the point was that users change the settings via just a simple page and not in a scripting language

A combined version approach wouldn't help in this case. We did breaking changes and we didn't keep compatibility with the old version (a major version bump is needed), so your plugin would still be rejected on load.

simple plugins that barely use the api, or use it in a simple way and wouldnt need to be rejected (litepresence should be one of them) since the api it uses didnt change at all

That's the approach they decided to take. We decided on a different approach. This PR simply extends how the mod-version works and formally forces us to keep compatibility with minor and patch bumps.

/shrug i think you should take the same approach since that's how yall usually gauge if to change behaviour or add features, and this is something that actually matters for users

Most users don't add complex API-dependent things to their user module...

statusview is a very good example of a simple thing which has changed in 2.1

Do users usually touch the StatusView? Anyways it keeps compatibility with the old API (with attached deprecation warnings), so I don't get your point here.

this is the only actual good argument to me that the separate versions would be wanted, but i guess that means apps shouldnt use semver at all?

Apps can use whatever versioning scheme they prefer. What benefits from semver are libraries (and APIs).

simple plugins that barely use the api, or use it in a simple way and wouldnt need to be rejected (litepresence should be one of them) since the api it uses didnt change at all

That requires versioned APIs which require a lot more effort.

/shrug i think you should take the same approach

And that's ok, but please stop bringing that up time after time when I already told you why that approach doesn't suit us.

since that's how yall usually gauge if to change behaviour or add features, and this is something that actually matters for users

What do you mean?

Anyways it keeps compatibility with the old API (with attached deprecation warnings), so I don't get your point here.

it shows a deprecation message and doesn't do anything, that's not keeping compatibility

What benefits from semver are libraries (and APIs).

guess what we have

And that's ok, but please stop bringing that up time after time when I already told you why that approach doesn't suit us.

yeah i give up already lol, that's how you have half reinvented and broken stuff in lite xl land

Anyways it keeps compatibility with the old API (with attached deprecation warnings), so I don't get your point here.

it shows a deprecation message and doesn't do anything, that's not keeping compatibility

It literally keeps compatibility with the old way? What else is it supposed to do?

What benefits from semver are libraries (and APIs).

guess what we have

Guess what's getting semver with this PR? Oh the API!

yeah i give up already lol, that's how you have half reinvented and broken stuff in lite xl land

You're free to use anything else.

You're free to use anything else.

ah yes, the perfect comment to anyone who says a piece of criticism and suggests something you dont like

as for the pr itself, this would only be major and minor and doesnt include patch, so you dont update on bugfixes and only api additions/breaking changes

so anyway is this going to be merged or not

At this point I would wait until we refactor everything that needs a refactor first (tab bar, path management, project files/dirs management, ...) to have a mostly static base, otherwise we'd need many bumps in a short amount of time.

So this change is currently high priority, now much more that we have a plugin manager. With the work done by Adam on lite-xl/lite-xl-plugins#211, ephemeral_tabs is going to be one of the first consumers that will need checking if the minor version matches the required target in order to properly load. This way we can allow plugins targeting mod api v3 to still work without any changes, and at the same time permit other plugins to explicitly request support for the newer non-breaking features.

To expand on what Guldo already described above and make sure of having a clear vision where this is heading, are these points right when the following numbers are increased?

• Major - Compatibility was broken for plugins depending on older version (eg: any of the core functionality or default shipped plugins overridable interfaces behavior changed on a non backward-compatible manner or just renamed/removed)
• Minor - New features were introduced without affecting previous functionality (eg: new facilities that can be used by plugins but aren't mandatory)
• Patch - Bug fixes or improvements only without affecting previous functionality (eg: corrections to erroneous behavior without changing the original end result)

Here is a patch to make this PR work against latest core regex changes:

diff --git a/data/core/init.lua b/data/core/init.lua
index 731cb4b7..9cfe2a87 100644
--- a/data/core/init.lua
+++ b/data/core/init.lua
@@ -937,21 +937,17 @@ local function get_plugin_details(filename)
 
   for line in f:lines() do
     if not version_match then
-      local _, _,
-        major_a, major_b,
-        minor_a, minor_b,
-        patch_a, patch_b = mod_version_regex:match(line)
-      local major, minor, patch
-      if major_a then
-        major = tonumber(line:sub(major_a, major_b))
+      local major, minor, patch = mod_version_regex:match(line)
+      if major then
+        major = tonumber(major)
         version_match = major == MOD_VERSION_MAJOR
       end
-      if version_match and minor_a then
-        minor = tonumber(line:sub(minor_a, minor_b))
+      if version_match and minor then
+        minor = tonumber(minor)
         version_match = (minor or 0) <= MOD_VERSION_MINOR
       end
-      if version_match and patch_a then
-        patch = tonumber(line:sub(patch_a, patch_b))
+      if version_match and patch then
+        patch = tonumber(patch)
         version_match = (patch or 0) <= MOD_VERSION_PATCH
       end
     end

Also Guldo, I will take the liberty of marking this as ready for review since we should work on this rather sooner than later now.

Should we leave a warning in the logs if we load a plugin with lower minor version?

Should we leave a warning in the logs if we load a plugin with lower minor version?

that could be a good way of easily debugging possible future issues/mistakes on our part, so feel free to do so, we should squash merge afterwards 😃

Mmm but thinking about it, all plugins that are 1 digit modversion eg: 3 will be logged, so maybe core log it if the plugin explicitly request a specific minor version?

Unspecified minor means 0, but if we're at a higher minor we should still log, as the plugin is not explicitly compatible with latest mod-version.

I wonder if this might pollute the logs too much tho.

I wonder if this might pollute the logs too much tho.

that is my point

We should then at least add the mod-version in the "Loaded plugin" log.

We should then at least add the mod-version in the "Loaded plugin" log.

that makes more sense, just adding to the info that is already logged