After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 776942 - Cannot download incompatible with current version?
Cannot download incompatible with current version?
Status: RESOLVED DUPLICATE of bug 776460
Product: website
Classification: Infrastructure
Component: extensions.gnome.org
current
Other Linux
: Normal normal
: ---
Assigned To: Shell extensions maintainer(s)
Shell extensions maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-01-06 12:33 UTC by Gautier Pelloux-Prayer
Modified: 2017-01-20 14:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Gautier Pelloux-Prayer 2017-01-06 12:33:06 UTC
On extensions.gnome.org, one can use for "Compatible with" drowdown button the value "All versions". It will display all extensions, as expected.

However, when selecting one of these extension, the switch to install it is still present but trying to install the extension will obiously fails because we are trying to download at url:

> https://extensions.gnome.org/download-extension/${EXTENSION_UUID}.shell-extension.zip?shell_version=${CURRENT_VERSION}

Since CURRENT_VERSION is set to… the current version, there is absolutely no chance that this URL exists so installation is failing (silently by the way, the switch stays on "ON" state). 

What is expected here? Should we be able to download the extension even if it might not work? Or should we not even try to install it and in this case the button should be hidden?
Comment 1 Florian Müllner 2017-01-20 14:03:35 UTC
I think this is (primarily) an issue of extensions.gnome.org - even when not filtering by version, passing the shell version makes sense in my opinion. If we have three extension versions for shell versions 3.18, 3.20 and 3.22, we want to pick the one that best matches the actual shell version (which isn't necessarily the newest one).

We might need some code on the shell side to pass through a strict-version=0 parameter (or similar), but the main issue here is that the website only matches the exact version instead of looking for the closest match, so reassigning.
Comment 2 Yuri Konotopov 2017-01-20 14:50:45 UTC
Florian, please see my comment #5 (especially item 2) from bug 776460.

I open for discussion here, because for now we have different vision about it.

*** This bug has been marked as a duplicate of bug 776460 ***