On 7/14/22 6:02 AM, Jiří Kovalský wrote:
Dne 14. 07. 22 v 13:15 Michael Bien napsal(a):
On 14.07.22 12:44, Neil C Smith wrote:
So we can .. use
the NB15 baseline as initial set for NB16+ as suggested by Matthias.
just an idea,
Yes. Using the previous release as the baseline set is far from a new
suggestion though,
well this was only a part what i was suggesting, it was supposed to
be a one time event linked to a notification mail.
however, thinking about this a bit more:
it is probably better to send the notification mail after the new
plugin portal changes are in. Since there is not really an advantage
to create that baseline earlier. So that all still-maintained plugins
can request the verification under the new model.
This would hopefully also pick up some of the 12.0-verified plugins
which disappeared from the plugin manager some time ago - assuming
the maintainers read the mail and press the button :)
-mbien
Sorry for coming late to this discussion.
Anyway, I very much like the idea of notification button which would
give owners of plugins supporting already released version 14 a chance
to quickly double check that their plugins work in version 15 and then
request official verification in that upcoming version. Maybe we could
send the notification around the time when 15 RC1 voting opens?
No RCx voting. "quickly double check" requires that plugin authors
download an RC and do the testing. I don't always download an RC, so
there's nothing quick about that.'
I like the model where, after a plugin' initial verification, they are
automatically included in the subsequent catalogs; a plugin becomes
"unverified" if there's a problem detected.
With this model, the issues/questions revolve around what it take to
unverify a plugin?
Perhaps the top <##>%, by download, are automatically scheduled for
verification? Maybe a plugin can be marked as dependent on
volatile/dynamic API's and so does not get automatic inclusion; there
could be a check a box that disables automatic inclusion in the next
catalog. There is nothing to prevent the plugin team from doing
verification even if it is not requested.
Simplifying/semiautomatic email notification, as needed, sounds good.
-ernie
BTW, I have already created version 15 in the Plugin Portal so that
owners can start requesting the verifications.
However, I am not not much in favor of getting rid of plugin
verifications completely. As Yarda pointed out we often see issues
with JDK such as these and I for one consider the manual verifications
useful:
https://github.com/moacirrf/nb-java-decompiler/issues/32
https://github.com/ranSprd/netbeans-pojomaker/issues/1
https://github.com/funfried/externalcodeformatter_for_netbeans/issues/178
My two cents,
-Jirka
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
