Dear Borys, for our plugin (the OpenQuake Integrated Risk Modelling Toolkit [1]) we have been very happy to use the "experimental" flag so far, and we consider it a very useful feature.
For us, the ideal workflow would be to release a new version of the plugin flagged as experimental, then let our scientific team try it extensively on real use-cases, and then mark it as stable. If I understand correctly, your proposal is to remove the possibility to mark an existing experimental version as stable, so we would have to release an identical version of the plugin without the "experimental" flag, as soon as we receive the approval from our scientists. >From a user perspective, we believe it is important that the user can actually trust our plugin for "production" purposes, as long as the plugin is not flagged as "experimental". Users that are willing to try new cutting-edge features at their own risk, can still enable experimental plugins and download the most recent version. We also have another important point in favor of keeping two different versions of the plugin. Our tool has to interface itself with the OpenQuake Engine [2], that is a scientific engine that evolves very quickly. We currently keep the most recent stable version of our plugin aligned with the latest official release of the OpenQuake Engine, ensuring compatibility between the two softwares. Between one official release and the next one, we release new experimental versions of the plugin, ensuring compatibility with the nightly builds of the OpenQuake Engine. Therefore, scientists that are interested in using the most recent features offered by the two softwares can rely on the nightly builds of the OpenQuake Engine and on the latest experimental OpenQuake Integrated Risk Modelling Toolkit. For the above reasons, our answer to your question is yes, we do really need this feature. And if you decide to drop it, we will have to significantly redesign our release workflow. Paolo Tormene, on behalf of the OpenQuake Team [1] https://plugins.qgis.org/plugins/svir/ [2] https://github.com/gem/oq-engine/ On Sun, Aug 26, 2018 at 8:11 PM Borys Jurgiel <[email protected]> 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. > > Initially it was designed for two cases: to mark a whole plugin as > experimental, and to just mark the recent version (so a kind of beta). > Both > cases seem to be popular among authors: at the moment we have 215 plugins > for > master, from which ~40 are experimental only and ~20 are in both versions. > > 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. 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? > > Regards, > Borys > > [1] https://github.com/qgis/QGIS/pull/7713 > > > > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- *PAOLO TORMENE* senior software developer +39 0382 5169882 *GLOBAL EARTHQUAKE MODEL * working together to assess risk *GEM -* globalquakemodel.org <http://www.globalquakemodel.org> *T -* @GEMwrld <http://twitter.com/GEMwrld> *F -* GEMwrld <http://www.facebook.com/GEMwrld>
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
