Ehhhhh? I’m not convinced the author has solved any problem in any useful way. I do think he is on the right track in specifying the semantics of a piece of software more thoroughly but his solution is to make a whole lot more work for anyone writing software. His alternative to version numbers are also not necesasrily useful. The value of a semantic version is that I can take two versions and quickly determine how much I need to be concerned about my dependent breaking. In this case, If I understand his proposal correctly, I will need to do a more thorough analysis in order to determine that, possibly reading multiple contracts.
Finally, and most importantly to me, is that the idea of software having a specification is great but his solution is no less ad-hoc than any version number system. We really need specs to be code that can generate tests rather than hope the author interpreted and implemented the spec and wrote their tests correctly. Until a spec can be turned into code trivially I think this idea is too much work for too little benefit.
I read this back when it was first posted and I thought it was pretty interesting. I read it now and I find myself thinking the same things that @apy mentions.
The discussion in the post doesn’t seem to solve much of anything with “the versioning problem”. It makes it more explicit to be sure (which is ultimately a good thing) but what’s to stop me from saying that my contract is called version A.B.C which implements some list of things found in the “software bill of materials”?
It boils down to “be more explicit”, which will probably be as successful as “we should all use statically typed languages”, or “you must document all your code”.
Versioning problems will not be solved by these kinds of approaches. @apy is on the right track: the dependency hell can only be broken if software “entities” can work out, without (mandatory) manual intervention, whether they can work/communicate together. Tests are one way to do that.
Ehhhhh? I’m not convinced the author has solved any problem in any useful way. I do think he is on the right track in specifying the semantics of a piece of software more thoroughly but his solution is to make a whole lot more work for anyone writing software. His alternative to version numbers are also not necesasrily useful. The value of a semantic version is that I can take two versions and quickly determine how much I need to be concerned about my dependent breaking. In this case, If I understand his proposal correctly, I will need to do a more thorough analysis in order to determine that, possibly reading multiple contracts.
Finally, and most importantly to me, is that the idea of software having a specification is great but his solution is no less ad-hoc than any version number system. We really need specs to be code that can generate tests rather than hope the author interpreted and implemented the spec and wrote their tests correctly. Until a spec can be turned into code trivially I think this idea is too much work for too little benefit.
I read this back when it was first posted and I thought it was pretty interesting. I read it now and I find myself thinking the same things that @apy mentions.
The discussion in the post doesn’t seem to solve much of anything with “the versioning problem”. It makes it more explicit to be sure (which is ultimately a good thing) but what’s to stop me from saying that my contract is called version A.B.C which implements some list of things found in the “software bill of materials”?
It boils down to “be more explicit”, which will probably be as successful as “we should all use statically typed languages”, or “you must document all your code”.
Versioning problems will not be solved by these kinds of approaches. @apy is on the right track: the dependency hell can only be broken if software “entities” can work out, without (mandatory) manual intervention, whether they can work/communicate together. Tests are one way to do that.