Stan,
thank you for reading the paper and your questions!
stan@stanheckman.com wrote:
What advantage do we get from separating 3 (downwards and upwards compatible) from 4 (small fixes)? Under what conditions would one ever want to accept a version that (supposedly) differs only by small fixes, but not accept a version that (supposedly) is downwards and upwards compatible?
The idea in my scenario has been, that each improvement - performance, storage, whatever - without changing the call semantics contains some risk of introducing *new* bugs. The 'small fixes' should be viewn as explained in the paper in section 'Application to packages->Versions->Classification issues': * But if a 'small' fix just makes the package working with some seldom * used other package being the only one running into the bug, then the * classification as 4. makes sense (3. may introduce new bugs affecting * many packages).
Directly there follows the relativization: * But if the fix removes some serious problems affecting many other * packages, it may as well classified as 2., since there is good reason to * view this as an important upgrade.
What advantage do we get from separating 5 (no code changes) from 3 and 4? In each of these cases, the author is stating that he or she thinks each version will generate the same results. Either we trust the author or we don't.
If the author is earnest, you can be *sure* that nothing breaks, if there hasn't been any code change (ignoring the possibility of changing the code by accident). But similar to the point above: if there is some code change there *always* is a risk of breaking something. I think it is worth to differentiate between these cases.
I guess some users would trust the author unless another user has sent a configuration report to SqueakMap asserting that the author is wrong for their particular configuration; while other users will not trust the author until some other user has sent in a report that exactly this configuration does work. But I guess bold users will trust the author in each of your cases 3, 4, and 5, while cautious users will not trust the author in any of these cases. Do you disagree?
These behaviors are all possible.
Do you think some users will trust the author when he or she says only comments have changed, but not trust the author when he or she says the code is upwards and downwards compatible?
Yes. But not so hard: 'not trust the author' in a sense that he could have made a mistake or that the software runs into not expected behavior (especially if interacting with packages the author is not responsible for!). And then I think it also depends on the author, if I'm willing to trust him/her more or less, and on the experiences I've made with the package in the past...
I wouldn't expect any *new* problems in case 5. (no code changes at all, stated by a respected maintainer), and therefore assuming a detected bug is an old one; but in every other case I would possibly look into the code changes or just try to install the previous version, if something seems to be broken.
Other points:
- The granularity of the proposed scheme is fine, but better too fine as too simple: nobody is forced to publish versions only changing in lower ranked version numbers, but it is possible. And it is also possible to be very fine granular in expressing conflicts with other package versions: from a singular version to larger and larger sets of versions.
- If the technical solution works in praxis, *strongly* depends on the people using it; in this case especially the package maintainers deciding into which category a package change belongs. In addition there could be some process, of course: web of trust between maintainers, classification in stable/unstable/etc., automatically testing of standard configurations, etc.. But in the beginning I don't expect and I don't like to have too much process: let's have a start first!
Greetings, Stephan