On Fri, 21 Oct 2022 at 12:43, Michael Bien <mbie...@gmail.com> wrote: > well, this was my first suggestion but it met resistance :)
I know. I agree with you. My issue with the resistance, and some points are definitely valid, is that it's based on a somewhat false idea of what we've been doing for the last few years of releases. > I would just leave everything verified. The community could filter > problematic plugins out which are not updated. We can't leave verified as far as I understand. We would need to bulk verify everything, unless we go back to a shared catalog. And if we go back to shared catalogs, we can't filter by release. Of course, we could have one catalog and unverify anything that doesn't work in the current or next release as an alternative? Leaves anyone sticking with older versions in an awkward position though. > > I still wish we'd gone down the route of managing plugins via a git > > repository! It would have simplified and opened up this process to > > all committers. > > interesting idea! It would have had the benefit that all imaginable > tooling would be already there and maintainers know how to use it. The "downside" (which I still consider the upside given licensing, etc.) was that it involved external plugin hosting (via GitHub releases, Maven, etc.) and metadata files in folders containing all info including file link and hash. Validation would be by PR with CI verifying and building a static catalog file. Best wishes, Neil --------------------------------------------------------------------- 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
