Sounds like you are proposing something different from what Till described. I think what you suggest is a fine alternative, and it does not conflict with the sane standard: https://sane-project.gitlab.io/standard/api.html#version-control We must be careful not to break compatibility, say by accidentally bumping the soversion.
allan On Mon, Dec 27, 2021 at 5:10 PM Ralph Little <skelb...@gmail.com> wrote: > Hi > I agree with this. Something I wanted to also propose. > > Cheers > Ralph > > On Mon, Dec 27, 2021, 13:04 Povilas Kanapickas <povi...@radix.lt> wrote: > >> Hello, >> >> The current versioning scheme does not allow proper bugfix releases of >> SANE backends. That is, only 3 components in the version are supported >> properly in the build scripts and elsewhere. For example version codes >> for 1.0.33.1 would be identical to 1.0.33. Version codes are the only >> thing that I found, there are likely other problems because people >> writing code did not expect a 4-component version. >> >> The above is bad, because e.g. if we release 1.0.33 and notice a serious >> problem, we can't release a bugfix without risking breakage in various >> places even if it's a single line change. >> >> Fixing all the code that expects 3-component version is probably not >> good use of the time we have. >> >> Therefore I propose we switch to increasing the second version component >> instead of the third for future releases of SANE. E.g. instead of >> 1.0.35, 1.0.36 and 1.0.37 we will have 1.2.0, 1.3.0 and 1.4.0 releases. >> This way we would have the third version component reserved for bugfix >> releases. >> >> I also propose to apply the proposal to the upcoming 1.0.33 release and >> use 1.1.0 version for it. >> >> Please let me know what you think. >> >> Regards, >> Povilas >> > -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand"