> > 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
