A public API is a commitment from the whole project. So, everybody lives with the consequences. Which means I would treat a friend API more or less public from the start and weigh my +1 accordingly.
--emi ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On 25 July 2018 7:20 PM, Tim Boudreau <[email protected]> wrote: > > 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 --------------------------------------------------------------------- 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
