Am 05.03.2018 um 22:23 schrieb Eduard Braun:
Am 05.03.2018 um 21:59 schrieb Maren Hachmann:
Am 05.03.2018 um 17:56 schrieb Eduard Braun:
Am 05.03.2018 um 13:31 schrieb Maren Hachmann:
However I'm not sure it works as I think it should as https://inkscape.org/en/release/ still points to the pre-release (which I assume it should not?). Maybe a caching issue?
- I tested after I changed it, and it didn't show up as primary download
for me (but it did change, so I assumed it had worked). I found that duplicated name ugly...
That's why I suggested to drop the codename field below... a single Version field should suffice IMO (as you note they are set to the same anyway if set at all).
According to the source code, what makes a pre-release a pre-release is not the 'pre' in its name, but that its parent (the release, in this case 0.92.3) does not have a date set, or the date is set after the pre-release's date.
(https://gitlab.com/inkscape/inkscape-web/blob/master/releases/models.py#L132)
If I'm not missing something this function is not used anywhere.
So the code name doesn't make a difference, we should be able to safely remove it again. May I try?
The codename *does* matter. I think the following code decides what the "latest release" is: https://gitlab.com/inkscape/inkscape-web/blob/master/releases/views.py#L56
- Yes, you're right. Confusing... @doctormo, can one of these two options that make a pre-release a pre-release be removed, then?
Maren
Now I also get 0.92.2 again when visiting https://inkscape.org/en/release/
Maren
As Inkscape does not use codenames for releases, maybe we can drop the codename field altogether?
Regards, Eduard