illumos inherited an Interface Stability taxonomy from Sun; see in particular Classifications in attributes(7). When we inherited them, they had relatively recently been changed to basically a two tier naming scheme: Uncommitted and Committed.
There used to be an Evolving classification which I think is a good name for the middle classification this article describes, but as noted in that manual page it was ultimately discarded because it was too hard for people to understand what it really meant. Some things were upgraded to Committed and then anything not specifically addressed is interpreted as being Uncommitted now.
I think the nuance and difficulty with Evolving is even more pronounced in the open source world, where people move a lot quicker, and they soft fork a lot more software with local patches, and there is just not a lot of scope for coordinating contracts between different consumers and the upstream per se. The classifications we use now ultimately reflect the binary of “have we promised, yet, that this will never change again?” which is, I think, ultimately what matters to consumers.
After thinking about it for a bit, I like your terms. The article proposes “experimental” (a fine name), “production ready” (a terrible name for the purpose), and “stable” (decent, but not ideal). But your set of names is each very clear, plus the alliteration makes the set feel “clever”.
Yes, and just as every few decades we benefit from a new translation of Plato’s Republic, every generation benefits from a re-interpretation of useful categories. Discarding, or de-emphasizing. Rediscovering, or recreating.
Consider one of the markers of the transition to the third phase:
early adopters empirically stop uncovering deficiencies in the API
This signals a quite different sociological context that emerged post 2000 and has been kicked into hyperdrive in the GitHub era. The early adopters are not your QA team with a list of requirements, but are something more like development partner who - in the best case - get to shape the project’s outcome. They pay innovation tokens but get something in return.
So we need something like SemVer to write tools that let cargo or go get mechanically upgrade our dependencies, but in that new context we need to reinterpret the aspects of the social contract that incrementing numbers can’t fully represent.
If you thought my comment was meant to trivialize your rediscovery, it was not. I was trying to contextualize it for you, connecting it to prior art that might inform further insights. Rather than invent new terms, i think you’d benefit from connecting to prior art.
illumos inherited an Interface Stability taxonomy from Sun; see in particular Classifications in attributes(7). When we inherited them, they had relatively recently been changed to basically a two tier naming scheme: Uncommitted and Committed.
There used to be an Evolving classification which I think is a good name for the middle classification this article describes, but as noted in that manual page it was ultimately discarded because it was too hard for people to understand what it really meant. Some things were upgraded to Committed and then anything not specifically addressed is interpreted as being Uncommitted now.
I think the nuance and difficulty with Evolving is even more pronounced in the open source world, where people move a lot quicker, and they soft fork a lot more software with local patches, and there is just not a lot of scope for coordinating contracts between different consumers and the upstream per se. The classifications we use now ultimately reflect the binary of “have we promised, yet, that this will never change again?” which is, I think, ultimately what matters to consumers.
Hmmm what about fluid, flexible, fixed
After thinking about it for a bit, I like your terms. The article proposes “experimental” (a fine name), “production ready” (a terrible name for the purpose), and “stable” (decent, but not ideal). But your set of names is each very clear, plus the alliteration makes the set feel “clever”.
When I was a youngun, we used to have names for these. You have independently rediscovered Alpha, Beta, and Release.
Yes, and just as every few decades we benefit from a new translation of Plato’s Republic, every generation benefits from a re-interpretation of useful categories. Discarding, or de-emphasizing. Rediscovering, or recreating.
Consider one of the markers of the transition to the third phase:
This signals a quite different sociological context that emerged post 2000 and has been kicked into hyperdrive in the GitHub era. The early adopters are not your QA team with a list of requirements, but are something more like development partner who - in the best case - get to shape the project’s outcome. They pay innovation tokens but get something in return.
So we need something like SemVer to write tools that let
cargoorgo getmechanically upgrade our dependencies, but in that new context we need to reinterpret the aspects of the social contract that incrementing numbers can’t fully represent.If you thought my comment was meant to trivialize your rediscovery, it was not. I was trying to contextualize it for you, connecting it to prior art that might inform further insights. Rather than invent new terms, i think you’d benefit from connecting to prior art.
I didn’t mean to imply that. I agree with you. Fwiw, I find this a fascinating topic with no universal solution.