Stan,

thank you for reading the paper and your questions!

stan at 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
-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3