> There should be no barriers in implementing functionality as plugins. Everything about programming and API design is making barriers.
Although, if you think about it there are no true barriers, you can use reflection to hack into almost every corner of NetBeans. But what you would ideally want is for a neat API that provides you all these hooks, so the plugin author does little work and NetBeans takes the burden of creating (and maintaining!) this open API. So, it's a false problem. The actual problem has always been the same: maintaining quality and backwards compatibility implies being intentional about the things we support and the things we don't. There is nothing stopping people suggesting API improvements and making PRs, but we can't just make everything public and call it a day. Because then the next release comes and all the existing plugins stop working (or... we can't evolve anymore since we commit to such a big public API that we painted ourselves in a corner). The idea of providing experimental features as plugins is cool but somebody will have to do the work for all the plumbing. Those experimental features won't just become new modules into core, they will just get absorbed into the existing codebase when they are fully baked. Nothing preventing this to happen even right now, there just is no such magical generic infrastructure for it to happen. > How is it with PHP, is it a plugin which can be updated when new versions are > released e.g. PHP 7.4, or do we need to wait until the next major release of > Netbeans to get support for new versions? Worse case scenario we are looking at a 3-6 months delay, correct? Although the problem won't be about the release date, it will be about making sure somebody actually implements the proper support for the next PHP dot release. Assuming we are proactive about that, I don't see why we wouldn't have an out-of-band release specifically to include our improved PHP stuff. These things are not set in stone. --emi On Fri, Nov 16, 2018 at 5:00 PM Ondro Mihályi <[email protected]> wrote: > > I fully agree. There should be no barriers in implementing functionality as > plugins. Before every NB release, the community could vote on plugins to > include in NB core to add their functionality into core. That would still > allow updating core plugins to a newer version without waiting for another > NB release. > > Dňa št 15. 11. 2018, 11:39 Christian Lenz <[email protected]> > napísal(a): > > > Hey, > > > > My 2 cents here again. First I want to know, what you think, how the minor > > Releases should look like. If they also contains Features, I’m fine with > > that two. > > > > I will be more fine to have only 2 releases, if we can have more public > > apis for other languages except Java. This is, IMHO a big Problem that a > > lot of stuff, can’t be done with 3rd-party Plugins for HTML, PHP, JS, CSS, > > etc. because of missing public APIs. If we have more public APIs, we can > > have more Features inside of NetBeans with only 3rd-party Plugins. > > > > We can’t adding hints and Code fixes for JS, CSS/LESS/SCSS, PHP or HTML > > which could make the work easier. And this is only one Little example. We > > can’t adding embedding languages to the mentioned languages. > > > > NetBeans first was build only for Java, this is why the Tokens of Java are > > public, the hints and fixes you can add with 3rd-party Plugins. So this is > > why you can add a lot of stuff to the Java Editor with 3rd-party Plugins. > > If we are open-source, we should open minded too to let the Developers > > decide, whether I want to add my feature into the core and wait 6 month > > after it is relased to the next Version or to add it via a Plugin and can > > bring it up today or tomorrow. > > > > > > Cheers > > > > Chris > > > > > > > > Von: Peter Hull > > Gesendet: Donnerstag, 15. November 2018 09:06 > > An: [email protected] > > Cc: [email protected]; [email protected]; NetCAT team; > > NetBeans Mailing List; [email protected] > > Betreff: Re: [DISCUSS] Apache NetBeans roadmap updates > > > > The 2 + 2 option makes sense to me. I'd be interested in hearing > > people's thoughts about how this lines up with JDK releases: > > * Is it better to do the NB testing after the general availability of > > the JDK, or aim to have them released about the same time? > > * What versions of JDK does Netbeans need to support, in terms of > > developing/building NB itself, running NB and developing Java > > applications using NB. (since there are alternatives to Oracle JDK I > > suppose we don't need to be influenced by Oracle's support scheme) > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
