In understand wanting to change the API without so many restrictions, but when the API hasn't changed for years, it seems like a fun activity spending a week making a proper API out of it. My original assumption was that the employer never gave developers that week because the time could be better used for something else.
Anyhow, just speculating. Under Apache though... I would not want to spend time stabilising somebody else's friend API unless I really need to use it myself. --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
