On Tue, Jul 24, 2018 at 11:02 PM, Emilian Bold < [email protected]> wrote:
> 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. > That's perfectly reasonable and exactly the same motivation as for working on anything else, e.g., bugs, adding features, etc -- i.e., scratch your itch, that's all. Gj > > --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]. > apache.org > > > 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 > > > >
