Hi Borys,
Personally, I think there is a need for the differentiation of
experimental or not experimental.
I'd like to keep it as it is.
Andreas
Am 27.08.2018 um 02:06 schrieb Nyall Dawson:
On Mon, 27 Aug 2018 at 04:11, Borys Jurgiel <li...@borysjurgiel.pl> wrote:
Hi Lists,
Before I make a QEP I'd like to know your general thoughts.
After I removed the deprecated plugins filter from the Plugin manager (and
make them always visible) [1], Alex suggested doing the same with the
Experimental status.
I'm -1 on this. Experimental plugins can be dangerous (some result in
crashes, data corruption, etc), and shouldn't be shown by default.
However, I'm not sure if it makes much sense nowadays. Releasing 'stable' and
'experimental' versions seems a bit overscaled to me. And there is a simpler
solution: If the recent version is buggy, users can just download the last
working one from the repo and install from zip.
I think that's overestimating some of our user's abilities -- it would
take a lot of knowledge that:
1. a plugin is at fault
2. they can overwrite a plugin manually with an earlier version
and
3. they can download earlier versions of plugins.
Then, they'd also need to know *which* older plugin version is "good"
and should be downloaded.
The former case, when the
whole plugin is experimental, seems to be often misused: authors can use it to
hide some specialised of localised plugisn from majority of users. In fact
even I committed such clear misuse, marking the Plugin Reloader as
experimental just to not clutter the list for normal users... Another reason
could be a shyness. But again, we have the rating stars now and don't need to
rely on the author's shyness anymore.
So... Do you see important reasons to keep this tag? Maybe we should
completely drop it? Or just remove the option to hide them from manager,
leaving the flask icon on the plugin details page?
I think it should be kept. I know of one buggy plugin which recently
got marked as experimental, and I'm *very* glad to see this particular
plugin hidden from the majority of our users by default.
Nyall
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
