-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version numbers don't match #69
Comments
Oh dammit, I just realized our last few releases didn't actually increment the version in meson.build. We really need to add a pre-commit check for that. I think it's safe for us to use the Explore plugin version instead of the Kolibri version in the About window. It's formatted the way it is in the Kolibri app because we want to center that, but in this case it's an implementation detail and we don't need to include it. I do think it's useful to have the app version as its own thing because it isn't necessarily in sync with the Explore plugin version, but indeed, the Explore plugin version is usually the more important one. So, something like And perhaps we can stick all those versions of things in a bit more detail in the |
Oops! Sorry, I forgot the one in And, back to the version number of endless-key-flatpak:
So, I suggest using the same scheme as Windows and Chrome OS: Sync the version's first two numbers of kolibri-explore-plugin. And, the 3rd number is the build number. |
This is a quick and dirty solution to maintain a single source of truth for the project version number. It means that builds will fail when run outside of a git checkout, but for our current needs, that should be fine. #69
This is a quick and dirty solution to maintain a single source of truth for the project version number. It means that builds will fail when run outside of a git checkout, but for our current needs, that should be fine. Helps: #69
This is a quick and dirty solution to maintain a single source of truth for the project version number. It means that builds will fail when run outside of a git checkout, but for our current needs, that should be fine. Helps: #69
I made #74 as a quick and easy solution to that version number for the desktop app itself being out of sync. It includes a change to the README, with a workflow that uses |
This adds a new workflow for creating releases, with a VERSION file that acts as a single source of truth for the project version number. Helps: #69
This adds a new workflow for creating releases, with a VERSION file that acts as a single source of truth for the project version number. Helps: #69
This adds a new workflow for creating releases, with a VERSION file that acts as a single source of truth for the project version number. Helps: #69
I don't think we should do tie the endless-key-flatpak version to the kolibri-explore-plugin version. What do we call the version when we make changes beyond kolibri-explore-plugin releases? It also essentially means we need to make an endless-key-flatpak release every time we make a kolibri-explore-plugin release. Otherwise the versions will be mismatched again. Which then ripples through to the org.endlessos.Key flathub build. We should be able to make new org.endlessos.Key releases when the explore releases but not endless-key-flatpak. I think it would be better if we had a way to specify the app version to the explore plugin so it could show that in addition to (or instead of) the plugin version. |
To provide a single source of information about the app, this commit adds debug info to the About dialog in the form of a JSON object dump. It includes the version of the application itself, the versions of essential Python modules, and runtime information about the Kolibri daemon service. Helps: #69
Instead of "kolibri_version (app_version)", show only the app version in the About dialog. Detailed version information is now listed in the troubleshooting section. Helps: #69
To provide a single source of information about the app, this commit adds debug info to the About window in the form of a JSON object dump. It includes the version of the application itself, the versions of essential Python modules, and runtime information about the Kolibri daemon service. Helps: #69
Instead of "kolibri_version (app_version)", show only the app version in the About window. Detailed version information is now listed in the troubleshooting section. Helps: #69
Instead of showing the project version, which is always one version behind, the version in the About dialog will appear as the output of `git describe --dirty`. Helps: #69
To provide a single source of information about the app, this commit adds debug info to the About window in the form of a JSON object dump. It includes the version of the application itself, the versions of essential Python modules, and runtime information about the Kolibri daemon service. Helps: #69
Instead of "kolibri_version (app_version)", show only the app version in the About window. Detailed version information is now listed in the troubleshooting section. Helps: #69
Instead of showing the project version, which is always one version behind, the version in the About dialog will appear as the output of `git describe --dirty`. Helps: #69
This adds a new workflow for creating releases, with a VERSION file that acts as a single source of truth for the project version number. Helps: endlessm/endless-key-flatpak#69
To provide a single source of information about the app, this commit adds debug info to the About window in the form of a JSON object dump. It includes the version of the application itself, the versions of essential Python modules, and runtime information about the Kolibri daemon service. Helps: endlessm/endless-key-flatpak#69
Instead of showing the project version, which is always one version behind, the version in the About dialog will appear as the output of `git describe --dirty`. Helps: endlessm/endless-key-flatpak#69
To provide a single source of information about the app, this commit adds debug info to the About window in the form of a JSON object dump. It includes the version of the application itself, the versions of essential Python modules, and runtime information about the Kolibri daemon service. Helps: endlessm/endless-key-flatpak#69
Instead of showing the project version, which is always one version behind, the version in the About dialog will appear as the output of `git describe --dirty`. Helps: endlessm/endless-key-flatpak#69
This adds a new workflow for creating releases, with a VERSION file that acts as a single source of truth for the project version number. Helps: endlessm/endless-key-flatpak#69
To provide a single source of information about the app, this commit adds debug info to the About window in the form of a JSON object dump. It includes the version of the application itself, the versions of essential Python modules, and runtime information about the Kolibri daemon service. Helps: endlessm/endless-key-flatpak#69
Instead of showing the project version, which is always one version behind, the version in the About dialog will appear as the output of `git describe --dirty`. Helps: endlessm/endless-key-flatpak#69
This adds a new workflow for creating releases, with a VERSION file that acts as a single source of truth for the project version number. Helps: endlessm/endless-key-flatpak#69
To provide a single source of information about the app, this commit adds debug info to the About window in the form of a JSON object dump. It includes the version of the application itself, the versions of essential Python modules, and runtime information about the Kolibri daemon service. Helps: endlessm/endless-key-flatpak#69
Instead of showing the project version, which is always one version behind, the version in the About dialog will appear as the output of `git describe --dirty`. Helps: endlessm/endless-key-flatpak#69
We have three places version numbers are shown:
Can we plan to align these? Otherwise it's going to be hard to know what version someone is actually using.
The text was updated successfully, but these errors were encountered: