Under Apache though... I would not want to spend time stabilising somebody > else's friend API unless I really need to use it myself.
You're misunderstanding my proposal. It is not that anybody spends time stabilizing someone else's API. It is that if a friend API stays de-facto stable for some period of time or releases, either the build system or the module system simply stops enforcing it being friends-only, at which point it is subject to the same compatibility requirements as declared to be stable modules. So it's not "imaginary person does the work", it's "if you don't do the work you'll have to live with the consequences". -Tim > > --emi > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On 24 July 2018 11:54 PM, Geertjan Wielenga > <[email protected]> wrote: > > > 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 > > > > --------------------------------------------------------------------- > 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 > > > > -- http://timboudreau.com
