FYI, it's never been a question of money. Developers working on NetBeans felt very comfortable keeping APIs under development via the friends API mechanism. Keeping the API in friend mode is much easier for a developer to make changes to it. No money at all involved in that thinking.
Gj On Tue, Jul 24, 2018 at 10:15 PM, Emilian Bold < [email protected]> wrote: > This idea might work if developers are employees and they will be paid to > stabilise friend APIs. But... this is the reason we got where we are: > Sun/Oracle didn't put enough money on the table for this kind of work. > > But under Apache... who's going to do the work? All I understand is that > when somebody introduces a new friend API they might break NetBeans builds > in about 2 releases. So, will I +1 that friend API? I might be more > inclined not to. > > Which means in practice we just stop using friends APIs. But... the need > friend APIs cover is still there. What will we use then? It might be > something even worse (like reflection, etc). > > --emi > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On 24 July 2018 10:49 PM, Tim Boudreau <[email protected]> wrote: > > > > I agree with Emilians comments (have a look at the end of this mail) > and > > > I want to add that I > > > like it to start with Friend-only API because then a potential user > must > > > become active to use > > > it. The user asks me to be added on the friend-list and I get his > e-mail > > > and I can ask him for > > > feedback in my answer. That is great. The main problem in the context > of > > > netbeans maybe is > > > that it needs additional time that the netbeans repository is updated > with > > > the information of > > > the list-change. Maybe other people are involved etc. But I am not > sure if > > > this is really a > > > problem. > > > > Historically, the problem has been: > > > > - Developer develops some modules with a friend API between them > > - Developer goes away / moves on to another project / loses access to > the > > repo > > > > - The modules stay in the distro, but other than someone updating them > in > > the case of API changes, nobody is touching the code > > > > - Somebody wants friend access to it > > - There is nobody to ask > > > > > > > I am afraid, that an automatism which makes friend APIs public after > some > > > versions will > > > produce more public APIs but with less quality. > > > > Oh, it's definitely a kind of social engineering. But so is making it > okay > > to have "unstable" APIs that remain that way for years with no code > > changes. > > > > We know what kind of results the current situation gets. If we want > > something different, we should do something different. > > > > > I like the situation that all public netbeans APIs are very stable and > > > have good quality. > > > > I like it too. I appreciate it every time I maintain a NodeJS project, > > where any library update almost invariably means rewriting a ton of code. > > > > > And > > > thats more important for me than having more APIs. But of course to > have > > > more APIs I will > > > like too. > > > > The point is to create a forcing function to stabilize friend APIs. As > in, > > either it needs to become a stable API by release X, or you have to use > > implementation dependencies and your module won't be usable across > NetBeans > > releases. That provides some motivation to stabilize an API. > > > > The Idee Peter presents: > > > > > https://stackoverflow.com/q/32555597/2999563 > > > I like too. It can be a nice additional feature to be used in the > friend > > > APIs. The more and > > > more stable the friend API will be, as less usage of @unstable > annotation > > > is used and if the > > > last position of the @unstable annotation is deleted than it is time to > > > make the API public. > > > > The endgame of that approach is the same mess NodeJS has - there won't be > > stable APIs. If you can just mark something unstable permanently (which > is > > the situation we already have), there's no reason to choose to commit to > > backward compatibility. The only thing that changes is it becomes > > module-developer-beware. > > > > Whereas actually making friend APIs into stable APIs if some set of > > conditions is met (say, has stayed compatible for two releases) like it > or > > not actually pushes the developer to stabilize the API. > > > > One gets you friend modules that are just called "unstable" which you can > > use, and when they break it sucks to be you. The other approach actually > > creates a process that forces APIs to be stabilized. > > > > Which is better for everyone in the long term? > > > > -Tim > > > > --------------------------------------------------------------------- > 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 > > > >
