How to version Liquid Prompt themes

[Rycieos]

Context

@Rycieos:

Let me know if you want me to wait to release v2.2 here... I don't think that is necessary; we could release v1.0 [in the liquidprompt-powerline repo].

@nojhan:

I also thought that it will be probably easier to understand for users if the themes follows the same versions than LP (i.e. being versioned 2.2.0 when they support LP 2.2.0). That way, you immediately know if the versions are aligned.

Problem statement

Versioning software that depends closely on other software is hard. The Liquid Prompt project is going to have a number of themes that are owned by the project, and determining how to version them is an important step. If we can agree on a good method, hopefully other community owned themes can follow the practice.

Options

1. Keep theme versions matching Liquid Prompt versions. This will make it very obvious when a theme will work with Liquid Prompt. The downside is new features or bug fixes can't be added without version drift happening.
2. Use a dual versioning system. Something like v2.2.0-1.0.0 for example. The first version being the Liquid Prompt version, and the second being the theme version. This could be confusing for users, and still locks each theme version to being compatible with exactly one Liquid Prompt version.
3. Force no relationship between versions, but have a compatibility matrix (example) that defines what versions work with what versions of Liquid Prompt.

My plan was to do 3), but I am open for feedback.

I really would like to see themes supporting multiple Liquid Prompt versions at once, but that might not be easy or even worth it.

I really do think that 1) is not a good idea, since there would be no way to fix bugs in a theme.

[nojhan]

1. If we stick to semantic versioning, then MAJOR.MINOR is sufficient to test for compatibility, and PATCH can vary between LP and themes. That way, bug fixes are possible in themes or LP without hindering compatibility tests and readability of the versions by the user.
   There may still be some issues when the themes do a backward-incompatible change against itself (like renaming a config variable), but I think it's a minor issue worth the effort.
2. This is easier on the devs, but complex for the users. At the same time, people are probably just cloning whatever is the last stable version of LP and theme, and just don't bother with versions anyway.

[Rycieos]

I like that. How would those versions be stored and displayed? Usually, with only one version, it can be the git tag name, and a simple string that is printed in help text and such.

[nojhan]

My themes have a version guard, with an hard-coded required LP version (e.g. in DotMatrix). Maybe LP can provide this as a function, so that theme would just have to call it with their supported version.

Using the git tag within the theme code would require a build step, which does not seems practical.

[Rycieos]

Don't we already have that with _lp_version_greatereq()?

[nojhan]

I was thinking of something more high level, like to have the theme set a prefixed variable __NAME_theme_required_version and let LP check when it loads the theme, and warn the user in case of mismatch.

[Rycieos]

Wow, that's such a good idea actually; it has grown on me all night. I'll bang out a PR for that quick.