Remove newin tags for 0.8.0 and lower from the wiki

[rmcode]

Hello,

I think newin tags should be removed for versions prior to 0.9.0 because I don't think they do anything other than creating noise on the pages - 0.8.0 is almost three years old after all. Personally I'd say we could go as far and just display them for 0.10.0.

By adding:

Code: Select all

{{#set:Since=000}}
{{#set:PrettySince=0.8.0}}

to the pages instead, the version info would still show up in the tables of each module.

I also think that the newin tag should generally be removed in cases where a oldin tag follows. E.g.:

Screenshot 2015-12-27 12.08.04.png (29.18 KiB) Viewed 1584 times

Any thoughts?

[bobbyjones]

I think having old docs would useful but maybe they can be archived and put somewhere else.

EDIT 1: I seemed to answered a different question rather than the one you asked lol. I think newin tags probably should only be for the newest release.

[airstruck]

0.8.0 is almost three years old after all

Before Debian 8 was released (on April 26th, 2015), Debian 7 shipped with Love 0.8.0. I'm sure not everyone has upgraded Debian yet, and everyone still on 7 will have Love 0.8.0 in the repo (I think Debian 8 has 0.9.1). Versions older than 0.8.0 might no longer be relevant, but you might still find people using 0.8.0.

I also think that the newin tag should generally be removed in cases where a oldin tag follows.

If a feature was added in 0.9.2 and removed 0.10.0, and you have version 0.9.1 installed, how do you know if that feature is available to you? You only know it was removed in 0.10.0, you don't know whether it was added before or after the version you're using.

I'm in favor of adding a small script to the wiki that filters out everything not relevant to the user's installed version. Here's a mostly finished userscript if anyone's interested in trying to move that forward: https://gist.github.com/airstruck/1603d55d79c469ac9fa6

[rmcode]

If a feature was added in 0.9.2 and removed 0.10.0, and you have version 0.9.1 installed, how do you know if that feature is available to you?

People could still see that by checking the tables.

[slime]

I think newin tags should be removed for versions prior to 0.9.0 because I don't think they do anything other than creating noise on the pages - 0.8.0 is almost three years old after all. Personally I'd say we could go as far and just display them for 0.10.0.

I'm in favour of removing them for version 0.6.2 and older to start (and keeping the tags, as mentioned below). I'd hold off on removing newin's for anything more recent until we make an actual decision.

Code: Select all

{{#set:Since=000}}
{{#set:PrettySince=0.8.0}}

Be sure to set the Since tag to the actual version, e.g. that should be {{#set:Since=080}}

I also think that the newin tag should generally be removed in cases where a oldin tag follows.

I've added a new "newinoldin" (I'm good with names, I swear!) template which still sets the Since and PrettySince tags automatically. It looks like this:

I'm in favor of adding a small script to the wiki that filters out everything not relevant to the user's installed version. Here's a mostly finished userscript if anyone's interested in trying to move that forward: https://gist.github.com/airstruck/1603d55d79c469ac9fa6

I also want that added – although I suspect it'll need more updating now that 0.10.0 is out and I've just added the new 'newinoldin' template.

[airstruck]

I suspect it'll need more updating now that 0.10.0 is out and I've just added the new 'newinoldin' template.

New releases shouldn't affect that script, it pulls the version history page to see what versions are available. New templates will affect it, of course. It could be future-proofed against new templates by adding some special attributes to templates that the script looks for, like data-newin="0.9.2" or similar. Then it would just be a matter of adding those attributes to any new templates. That might be a good idea anyway; the current text-scraping approach is brittle and will fall apart if the templates are re-worded or localized.

[Karai17]

I maintain that we should be switching the documentation to an actual documentation tool and not shoehorning it into mediawiki. It would allow us to compile different versions of the docs for different versions of love with no ambiguity.

[bobbyjones]

But the wiki is nice. It looks pretty.

[Karai17]

You can stylize any website to look pretty. That is a non-issue.