https://bugs.documentfoundation.org/show_bug.cgi?id=164790
--- Comment #9 from Emiliano Vavassori <[email protected]> --- (In reply to Piotr Osada from comment #8) > @Emiliano, I've read your entire comment 7 and cannot see any consideration > about automated information on the website [1] (Download / LibreOffice as > AppImage). Is this solution still not as simple as it might look like? You are right, I didn't add much. The point is: the actual page has static content (means: no dynamic content at all), has been changed last time a year ago or something like that, and (if not yet, soon) TDF wants to convert all its sites to static generated sites with Hugo. That means that if you want to show the version on the AppImage page, you need to alter it each time the page is regenerated (likely, for releases). Which is, indeed, more work than of now. I bet there's a way to automate all of this, which would be very dependent on how the website adjustment process at release time looks like. Unfortunately I don't have the skills, nor the energies to do that kind of task. Besides, the pipeline I built to release the AppImages follows strictly (well, more or less, depending on your understanding of "strict" on a temporal scale) the official releases. So if you come to the website some days after the official release of a new "still" version, you can be sure the version you are downloading with the different "Download still" links is the one for the newly release version that you expect, the one that you can see on the official binaries page under the "Still" version. The issue, in my perspective, is when you are reaching the download page right after the announcement of a new release (with your definition of "right after" being the key here). Since the polling mechanism of my pipeline, as explained previously, it would take up to 2 hours to have a new release converted to AppImages (I trust the pipeline, since it failed a couple of times in years of running). That doesn't mean you don't have any way to know if the repackage has been concluded or not: you can check in the "LibreOffice AppImage repository", which is linked right below the other download links, and search for the version you need. If the version is there, great! the new version has already been repackaged and you can even download it from there (and then you will download an AppImage with a fully versioned name), but if you still want to proceed with the links in the AppImage download page, you will still be getting the version you expect, although the name of its file will be generic, as you initially reported. If the version you are searching is not in the LibreOffice AppImage repository, it has not been built yet. If this happens days after the release, well, most probably the pipeline failed and you can contact me to have it checked (although I receive a notification when a single build fails so I should be already aware). I'll reiterate: I am not saying nothing needs to be changed, and I am definitely open to practical suggestions on how to improve the page and/or the process; I'm just very fond of my spare time and I am definitely not adding more effort to this endeavor. You are of course free to criticize the solution and contribute, but maybe it would be better if you understand the actual setup first and then provide technical solutions, more than wishes :) For sure, I see this is the right place to discuss technical improvements, so you are still definitely on the right track. -- You are receiving this mail because: You are the assignee for the bug.
