4 ms·

Is it a breaking change if a button is moved by a few pixels in a graphical application?

lostcolony 4y ago
No, because the functionality is the same. Just because a test may be so brittle that it breaks the test does not change the meaning (it just may mean you have to manually inspect the now failing test). The point is that most patch upgrades can just be run through a test suite and accepted. That may still lead to breakages, something that seemed minor and non-breaking to the developer could instead be breaking for a given user, but the point of semver is to convey actionable meaning and intent, which it does.
orphea 4y ago
Yes. Also several weeks of beta are required before releasing the change, and a few blog posts about how a talented team at $COMPANY deals with challenges of UI design.
jph 4y ago
If the application documentation promises a stable screenshot, but an update moves a button, then yes this is a breaking change. This comes up in the real world sometimes such as with automatic testing scripts that use absolute cursor positioning, as well as in some kinds of compliance where any graphic change requires a compliance verification of the new UI.
runaway 4y ago
The first two responses to you were a solid yes and a solid no. I think that just demonstrates how the concept does not apply to application versioning.
- lostcolony 4y ago
  One of the "Yes" responses is clearly sarcastic; the other gives an "only if you promise an unchanging UI".
  - runaway 4y ago
    The yes I saw at the time has been deleted or edited I believe
- jjav 4y ago
  It most certainly applies, the previous poster gave good examples of config files syntax and semantics, db compatibility, etc, etc. On the UI front it really depends, you need to make decisions and let users know to avoid surprises. At Sun the process was that every possible interface that something or someone can depend on is acknowledged to be an interface. Is GUI pixel positioning an interface? Well yes, clearly it is as someone could write tools that rely on that position. But do you as the author want to give users an assurance that you won't break this except in major releases? Maybe not. So interfaces were classified on the axis of public/private and stable/unstable (it was a bit more complex but that's the gist). Most applications used to classify the GUI elements as an unstable interface. Then you document that so consumers of the application know they shouldn't rely on GUI elements not moving.
  - runaway 4y ago
    I was specifically trying to contrast programming interfaces against the large universe of applications that don’t expose any. You bring up an interesting point about external dependencies such as db, however I would say the vast majority of these applications I refer to don’t rely on users to set these up.

No, because the functionality is the same. Just because a test may be so brittle that it breaks the test does not change the meaning (it just may mean you have to manually inspect the now failing test). The point is that most patch upgrades can just be run through a test suite and accepted. That may still lead to breakages, something that seemed minor and non-breaking to the developer could instead be breaking for a given user, but the point of semver is to convey actionable meaning and intent, which it does.

orphea 4y ago

Yes. Also several weeks of beta are required before releasing the change, and a few blog posts about how a talented team at $COMPANY deals with challenges of UI design.

jph 4y ago

If the application documentation promises a stable screenshot, but an update moves a button, then yes this is a breaking change. This comes up in the real world sometimes such as with automatic testing scripts that use absolute cursor positioning, as well as in some kinds of compliance where any graphic change requires a compliance verification of the new UI.

runaway 4y ago

The first two responses to you were a solid yes and a solid no. I think that just demonstrates how the concept does not apply to application versioning.

lostcolony 4y ago
One of the "Yes" responses is clearly sarcastic; the other gives an "only if you promise an unchanging UI".
- runaway 4y ago
  The yes I saw at the time has been deleted or edited I believe
jjav 4y ago
It most certainly applies, the previous poster gave good examples of config files syntax and semantics, db compatibility, etc, etc. On the UI front it really depends, you need to make decisions and let users know to avoid surprises. At Sun the process was that every possible interface that something or someone can depend on is acknowledged to be an interface. Is GUI pixel positioning an interface? Well yes, clearly it is as someone could write tools that rely on that position. But do you as the author want to give users an assurance that you won't break this except in major releases? Maybe not. So interfaces were classified on the axis of public/private and stable/unstable (it was a bit more complex but that's the gist). Most applications used to classify the GUI elements as an unstable interface. Then you document that so consumers of the application know they shouldn't rely on GUI elements not moving.
- runaway 4y ago
  I was specifically trying to contrast programming interfaces against the large universe of applications that don’t expose any. You bring up an interesting point about external dependencies such as db, however I would say the vast majority of these applications I refer to don’t rely on users to set these up.