@ognarb I can do it, I am just confused about "Multiple branches should be supported (stable, unstable, vintage, ...)".

Also displaying an information from config file to a template is easy but in the case of Kmymoney, it's all index.html, they should be converted to markdown files and rendered as HTML by Jekyll.

@atem Development is done in master branch, so no version numbers there. However, we do make releases from both 5.0 and 4.8 branches.

@atem in case you need to adjust the HTML and want to convert it to markdown, please feel free to make suggestions. This seems to be a leftover from the conversion to jekyll.

@ostroffjh, Still I don't get what you mean. For Plasma Desktop, it's written "Latest Release: Plasma 5.18 LTS" even if they do fixes older releases. So just a variable in _config.yml like kmymoney_latest_version: 5.0.8 and display it in the homepage is easy. If you need something more advanced, I need more details how you want it displayed.

@tbaumgart I need to inspect the KDE theme and how it was made for other KDE jekyll websites.
In an ideal world, you would just fill in some informations and the website should be rendered without anyone writing html.
You can see an example for my website where I am using the theme Minimal Mistakes : https://raw.githubusercontent.com/Atem18/kmdotnet/master/_pages/index.md

Feel free to ask if you need more informations.

@atem Don't worry to much about the enclosing HTML. As I mentioned, that was the q&d way to get the jekyll supported version going. It's the content that should be kept. We don't care if it comes out of a config file (preferred) or not. I agree, it is easier to maintain. Regarding the versions: we have a latest based on KF5 (stable) and one on KDE4 (vintage is a cool name). The versions available for download maybe different, depending on the OS environment. Here is how we displayed different versions in the old days of the project (Example).

@tbaumgart ok then no problem, we can do something like Libreoffice : https://www.libreoffice.org/download/download/

Like two squares, one called stable, the other vintage. Or one square that contains both version like the old website.
It can also be two buttons. Decide and I can do it.

I wish it were that simeple :-) Although we have both current (5.0.x) and vintage (4.8.x) releases, we have several "versions" of each, especially depending on platform. For Linux, it's source, appimage, or get it from your distribution. For Windows, there are multiple paths, depending on build system (craft or cross compiling) and build system (autotools or msys, and I may have these wrong). There's also MacOS. That multiplicity is unfortunate, but due to not all combinations being able to deliver all functionality and components successfully. However, I think it would be really cool if we could do something like LibreOffice - a drop down for each version with an entry for each available download. That would complement and not replace the current different page for each build type with an entry for each version - especially the CI services with daily entries. Bottom line, however, is the simplest thing we need is just to have the most recent 5.0.x and 4.8.x releases listed, perhaps with release dates, on the main page.

Ok then in that case may I suggest to do like Vscode guys did : https://code.visualstudio.com/

You have a button with a dropdown that list many downloads and also other downloads that when you click go to a special page that list all downloads like we do with https://kmymoney.org/download.html

Also I am on mobile right now and I saw that the top menu does not work on mobile. But that a problem of the KDE thème because even the Konsole website has the same issue.

When it comes to automation, it is a perfect job for GitLab pipelines which can handle additional steps post-release. What I suggest is that the pipeline auto-updates the version.yml file with most recent version, and the version.yml to be incorporated into the html.

@wrobelda Since there is multiples versions, you cannot use something like a Git tag to replace a placeholder in the _config.yml file.

At least for now, the best is probably to just change the releases version by hand like KDE does : https://invent.kde.org/websites/kde-org/-/blob/master/plasma-desktop.php

@atem I don't see why this would be a problem at all for automation, we can maintain multiple stable release placeholders in _config.yml for both KMyMoney5 and KMyMoney4 stable branches and it is absolutely not a problem to make Gitlab Pipelines aware of that.

@wrobelda Ok if you have more details on how you would do it, I am interested. Also @ostroffjh what do you think about the dropdown on the homepage ?

@atem Sorry, what dropdown? I see buttons for "Install KMyMoney >" and "Download" which both go to the Download page, but no dropdown. Is there a draft home page? (Minor issue - all the items on the menu line keep the same menu line, except for "Donate" which is the main KDE Donate page, not KMM specific. I don't remember if we ever had a KMM Donate page.)

In T12566#231526, @atem wrote:

Ok then in that case may I suggest to do like Vscode guys did : https://code.visualstudio.com/

You have a button with a dropdown that list many downloads and also other downloads that when you click go to a special page that list all downloads like we do with https://kmymoney.org/download.html

Also I am on mobile right now and I saw that the top menu does not work on mobile. But that a problem of the KDE thème because even the Konsole website has the same issue.

@ostroffjh I am speaking about that comment.

Ah - if you mean using something like the dropdown on the vscode/visualstudio page, I do like it. Right now, it seems it's always two steps - go to the download page, then go to a separate page for the type of build, then pick your version. Saving one step for the latest version of each build type could be good.

@ostroffjh Ok I can do a draft in a git branch. After for the multiples releases numbers, I am waiting on @wrobelda answer.

@atem You could use something like this:

---
downloads: 
    - flavor: KMyMoney5
      platform: macos
      compiler: clang
      download: url
      sha256:
      git_hash:
    - flavor: KMyMoney5
      compiler: msvc2019
      platform: windows
      download: url
      sha256:
      git_hash:
    - flavor: KMyMoney5
      platform: appimage
      download: url
      sha256:
      git_hash:
    - flavor: KMyMoney4
      platform: appimage
      download: url
      sha256:
      git_hash:

Even better, take it a step further and create a folder structure (as explained here: https://jekyllrb.com/docs/datafiles/), e.g.:

_data\downloads\
_data\downloads\windows
_data\downloads\windows\desc.yaml
_data\downloads\windows\stable\kmymoney4.yaml
_data\downloads\windows\stable\kmymoney5.yaml
_data\downloads\windows\testing\kmymoney5.yaml
(...)

with desc.yaml having more generic information about the platform:

full_name: Microsoft Windows
icon_file: windows_logo.png
installation_instructions: windows_install.html

You get the gist. That having said, you may want to take this work upstream and coordinate with KDE Web team (Telegram: https://t.me/KDEWeb, https://community.kde.org/KDE.org), since this sounds like something worth adding to the generic Jekyll template they maintain and we use: https://invent.kde.org/websites/jekyll-kde-theme.git

We would update those _data\downloads by hand until we automate the Pipelines in GitLab, at which point marking a Release in GitLab will automatically generate and replace an adequate file in kmymoney-org repository.

BTW. I like the "Insiders" name more than "Unstable" or "Testing". It's more encouraging (an elite 'Insider' club? hell YEAH!) yet still signalizes bleeding-edginess.

I am all for automation when it is documented or self-explanatory. The structure sounds like a good idea as it is extendable.

I think the best way would be to store the information in AppStream files and fetch the release data from there.

This information is already stored in Krita for example: https://invent.kde.org/graphics/krita/-/blob/master/krita/org.kde.krita.appdata.xml#L450

The full documentation is located here: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-releases

This would allows to also display this information in kde.org/applications and in discover and other Linux stores.

Fetching the information from a remote git repository should probably be possible by writing a custom Jekyll plugin similar to https://github.com/brockfanning/jekyll-get-json.

@wrobelda Yes _data files are one way to solve the problem. I am just worried that it's becoming a nightmare to manage.
Yes we could upstream some work done here upstream but only if it's adopted as a standard by others projects.

@ognarb XML could be ok if it's first converted to JSON, then injected to _data so we can attack the data via templating. We could just create a that simple plugin based on that one : https://github.com/mcred/jekyll-xml-source/blob/master/jekyll_xml_source.rb to instead just load a local file.

@ognarb agreed, this is a better, universal solution

@atem yes, this would actually be great. And since the app appstream is standardized, it could make sense to make that plugin a separate project if you wanted to.

@wrobelda My mistake, I thought that the file would be in Kmymoney website repo but it should be in Kmymoney software repo. So the exact plugin I linked can be used as is.

@atem it could be in both, an automatic job to push the appstream xml from kmymoney repo to kmymoney-org would be easy to add. Still, better to use a single source and kmymoney own repo is best suited for this.

I agree with @wrobelda at this point. The website should reflect the work of the development team.

Ok then if there is an appdata like in Krita, I can use it to get the latest versions.

I added it as a subtask to https://invent.kde.org/office/kmymoney/-/issues/8 so we will have it in the upcoming release

Ok so the first thing you need to do is to update https://invent.kde.org/office/kmymoney/-/blob/master/kmymoney/org.kde.kmymoney.appdata.xml.

Then you can add a Rakefile in the website repo with a content similar to this:

task default: %w[build]

task :build do
  system 'wget https://invent.kde.org/office/kmymoney/-/raw/master/kmymoney/org.kde.kmymoney.appdata.xml'
 system 'appstreamcli convert org.kde.kmymoney.appdata.xml _data/appdata.json'
end

and then the appdata should be usable in Jekyll. Note that for the conversion to json to work we need an unreleased version of the cli util: https://github.com/ximion/appstream/issues/267

@ognarb then maybe we can just do it in plain ruby, that way we avoid executing commands on the system and avoid external dependencies like appstreamcli to be installed

My current ruby skills are very poor but if you believe that it can be done in plain ruby it is even better :)

@ognarb Well as I said earlier, that one is pretty straightforward : https://github.com/mcred/jekyll-xml-source/blob/master/jekyll_xml_source.rb
It downloads from an URL, convert XML to JSON and save it to a file. We don't need more, right ?

yeah we don't need more :)

Initial information about the last released source code file added to the master branch in https://invent.kde.org/office/kmymoney/commit/f0008d9c24f69adf8cf8c9a239be30b729b1ccf2

@tbaumgart thanks then I can make some tests

It would also be good to have quick links to the ChangeLog and Release Notes for the latest released versions. Before I add too many details, should I open a new issue on invent.kde.org or add it here?

@ostroffjh Agreed. The AppStream spec defines the following:

A release may also have an url tag as child. The release url should point to detailed release notes that explain the changes made in this particular release. The url tag may have a type property with details as the only currently allowed value. If the type is missing, an URL type of details is implicitly assumed.

So the Release Notes can be totally added to the website based on the information provided by the appstream xml file itself. To use the VS Code website as an example again, I like how they display a panel at the top of the page with the most recent release: Version 1.46 is now available! Read about the new features and fixes from May.

And then, once clicked, it presents with a nice changelog, accompanied by a chronological navigation on the left: https://code.visualstudio.com/updates/v1_46 . Obviously we don't need to go as far, especially that our rather infrequent releases don't lend themselves to a blog-like VS Code release notes, and even then this would a different issue, but their landing page approach is a nice touch.

That sounds fine. The current website requires you to click "News" then a specific release, and then there are links for the releast notes (just a list of bugs fixes) and for ChangeLog (the git log since the last release.) A more direct link to either or both of those is an improvement. I had separately emailed Thomas about trying in the future to have a more user-friendly description of the change associated with each commit or bug closure, but that's for a future discussion, I think.