Even though they're called 'private' they're not really private though. So saying
> open source projects have private APIs too
Is misleading (and unethical).
As far as APIs go, most project have a system to rate features called a stability index. Developers should take note and me aware of it. If something looks like it's going to be broken in the future, don't use it.
I'd also like to add that if you don't update apps on an iPhone they all start getting really slow. So iOS apps already do need to be updated.
Stability: 0 - Deprecated
This feature is known to be problematic, and changes are
planned. Do not rely on it. Use of the feature may cause warnings. Backwards
compatibility should not be expected.
Stability: 1 - Experimental
This feature was introduced recently, and may change
or be removed in future versions. Please try it out and provide feedback.
If it addresses a use-case that is important to you, tell the node core team.
Stability: 2 - Unstable
The API is in the process of settling, but has not yet had
sufficient real-world testing to be considered stable. Backwards-compatibility
will be maintained if reasonable.
Stability: 3 - Stable
The API has proven satisfactory, but cleanup in the underlying
code may cause minor changes. Backwards-compatibility is guaranteed.
Stability: 4 - API Frozen
This API has been tested extensively in production and is
unlikely to ever have to change.
Stability: 5 - Locked
Unless serious bugs are found, this code will not ever
change. Please do not suggest changes in this area; they will be refused.
>Even though they're called 'private' they're not really private though. So saying "open source projects have private APIs too" Is misleading (and unethical)
I call BS. And I'm offended by the "unethical" part.
First, they are totally private. Private is a well defined term in software engineering. It's a specific designation of code as a "you should not bypass this" by the developers.
Some languages have specific keywords for this very purpose (such as, well, the keyword "private"). Others use some tricks like "_" prefix to mark functions for internal use. In any case, you are not supposed to use those and mess with it.
And while you might get away with not obeying that in an open source program (if you consider your app breaking when that API changes upstream "getting away with it"), that's not the case in close source, long term supported platforms, where you don't want to have paid users shouting at you, or having to maintain some half-written, immature version of your API just because some idiot used it before it was ready.
>As far as APIs go, most project have a system to rate features called a stability index.
Private APIs are supplementary to the "stability index" contract. It means "this is subject to change and/or this is meant for internal use only".
There's not a large project that doesn't have private APIs. Including Open Source ones, like Java or Mono or Boost, etc etc.
>I'd also like to add that if you don't update apps on an iPhone they all start getting really slow. So iOS apps already do need to be updated.
Not sure where you got that from. That doesn't even make sense, computing wise. Apps run at the same speed at all times for the same inputs. The only time you might need to update them is when the OS and underlying libraries change incombatibly. Surely not to make them "go faster".
(Whereas a programmer has made the new version faster is beside the point. He might as well made the new version slower and more bloated. The thing is, apps do not get "slower" as time goes by. Perhaps you conflate them with something like disk fragmentation?).
> open source projects have private APIs too
Is misleading (and unethical).
As far as APIs go, most project have a system to rate features called a stability index. Developers should take note and me aware of it. If something looks like it's going to be broken in the future, don't use it.
I'd also like to add that if you don't update apps on an iPhone they all start getting really slow. So iOS apps already do need to be updated.
Stability: 0 - Deprecated This feature is known to be problematic, and changes are planned. Do not rely on it. Use of the feature may cause warnings. Backwards compatibility should not be expected.
Stability: 1 - Experimental This feature was introduced recently, and may change or be removed in future versions. Please try it out and provide feedback. If it addresses a use-case that is important to you, tell the node core team.
Stability: 2 - Unstable The API is in the process of settling, but has not yet had sufficient real-world testing to be considered stable. Backwards-compatibility will be maintained if reasonable.
Stability: 3 - Stable The API has proven satisfactory, but cleanup in the underlying code may cause minor changes. Backwards-compatibility is guaranteed.
Stability: 4 - API Frozen This API has been tested extensively in production and is unlikely to ever have to change.
Stability: 5 - Locked Unless serious bugs are found, this code will not ever change. Please do not suggest changes in this area; they will be refused.