[GH-ISSUE #275] Forward compatibility of persistent data #1932

New Issue

GiteaMirror · 2026-04-20T09:44:54-05:00

GiteaMirror commented

2026-04-20 09:44:54 -05:00

Originally created by @danielshahaf on GitHub (Sep 27, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/275

Subversion's release numbering scheme is approximately(?) semver, but additionally also allows to infer client-server compatibility and persistent-on-disk-data compatibility from the version numbers. I wonder whether semver should be discussing either of those aspects.

For example, Subversion promises that release A.B.x will be able to read files created by release A.C.y if B ≥ C. In particular, A.B.x is promised to be forward compatible with any later A.B.y, so downgrades from A.B.y to the earlier A.B.x will be possible. Should semver be making a similar promise about forward compatibility? It would be relevant to any software that uses its own file format.

(I didn't find any discussion of forward compatibility in v2.0.0.)

Originally created by @danielshahaf on GitHub (Sep 27, 2015). Original GitHub issue: https://github.com/semver/semver/issues/275 [Subversion's release numbering scheme](https://subversion.apache.org/docs/community-guide/releasing#release-numbering) is approximately(?) semver, but [additionally](https://subversion.apache.org/docs/community-guide/releasing#release-compat) also allows to infer client-server compatibility and persistent-on-disk-data compatibility from the version numbers. I wonder whether semver should be discussing either of those aspects. For example, Subversion promises that release A.B.x will be able to read files created by release A.C.y if B ≥ C. In particular, A.B.x is promised to be forward compatible with any later A.B.y, so downgrades from A.B.y to the earlier A.B.x will be possible. Should semver be making a similar promise about forward compatibility? It would be relevant to any software that uses its own file format. (I didn't find any discussion of forward compatibility in v2.0.0.)

GiteaMirror closed this issue

2026-04-20 09:44:54 -05:00

GiteaMirror commented

2026-04-20 09:44:55 -05:00

@FichteFoll commented on GitHub (Sep 27, 2015):

Yes, this is pretty much exactly what semver promises, except it's not explicit about file formats but anything that has a public interface. File formats would fall under that in most situations.

Alternatively you can versionify the file formats themselves, but incompatible changes should most likely also cause a major increase of the main application.

@FichteFoll commented on GitHub (Sep 27, 2015): Yes, this is pretty much exactly what semver promises, except it's not explicit about file formats but anything that has a public interface. File formats would fall under that in most situations. Alternatively you can versionify the file formats themselves, but incompatible changes should most likely also cause a major increase of the main application.

GiteaMirror commented

2026-04-20 09:44:55 -05:00

@danielshahaf commented on GitHub (Sep 27, 2015):

Of course file formats are a form of API. My point is that semver doesn't talk about forward compatibility at all: it does not promise that downgrading from 1.2.3 to 1.2.1 will be possible.

@danielshahaf commented on GitHub (Sep 27, 2015): Of course file formats are a form of API. My point is that semver doesn't talk about forward compatibility at all: it does not promise that downgrading from 1.2.3 to 1.2.1 will be possible.

GiteaMirror commented

2026-04-20 09:44:56 -05:00

@FichteFoll commented on GitHub (Sep 27, 2015):

I think it does. You are not allowed to add funtionality (minor) or break functionality, e.g. remove it, (major) in a patch release. So what else could happen?

@FichteFoll commented on GitHub (Sep 27, 2015): I think it does. You are not allowed to add funtionality (minor) or break functionality, e.g. remove it, (major) in a patch release. So what else could happen?

GiteaMirror commented

2026-04-20 09:44:57 -05:00

@danielshahaf commented on GitHub (Sep 28, 2015):

1.2.3 could upgrade the on-disk file to a format that 1.2.2 doesn't know how to read.

This would not be an API change or a new feature if the existence of the file is an implementation detail.

@danielshahaf commented on GitHub (Sep 28, 2015): 1.2.3 could upgrade the on-disk file to a format that 1.2.2 doesn't know how to read. This would not be an API change or a new feature if the existence of the file is an implementation detail.

GiteaMirror commented

2026-04-20 09:44:57 -05:00

@jwdonahue commented on GitHub (Dec 9, 2017):

@danielshahaf

Of course file formats are a form of API. My point is that semver doesn't talk about forward compatibility at all: it does not promise that downgrading from 1.2.3 to 1.2.1 will be possible.

It literally requires that 1.2.3 only has non-breaking bug-fixes, relative to 1.2.1, but it does not require that you can safely roll-back from 1.2.3 to 1.2.1. In most cases you probably can, but any newer version could modify undocumented private data structures in order to fix those bugs, so it could require an uninstall followed by an install, and data loss could happen. The spec is (rightfully) mute on roll-back capabilities.

Unless you have further questions, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Dec 9, 2017): @danielshahaf > Of course file formats are a form of API. My point is that semver doesn't talk about forward compatibility at all: it does not promise that downgrading from 1.2.3 to 1.2.1 will be possible. It literally requires that 1.2.3 only has non-breaking bug-fixes, relative to 1.2.1, but it does not require that you can safely roll-back from 1.2.3 to 1.2.1. In most cases you probably can, but any newer version could modify undocumented private data structures in order to fix those bugs, so it could require an uninstall followed by an install, and data loss could happen. The spec is (rightfully) mute on roll-back capabilities. Unless you have further questions, please close this issue at your earliest possible convenience.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1932