[sane-devel] Changing versioning scheme (1.1.0, 1.2.0, 1.3.0 instead of 1.0.33, 1.0.34, 1.0.35)

Povilas Kanapickas povilas at radix.lt
Mon Dec 27 23:18:46 GMT 2021


On 12/28/21 12:27 AM, m. allan noah wrote:
> 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
> <https://sane-project.gitlab.io/standard/api.html#version-control>
> We must be careful not to break compatibility, say by accidentally
> bumping the soversion.

I'd say my proposal is a subset of what Till described. I wanted to
limit the scope and only solve the primary concern of making the third
version component available for bugfix releases. I think long term the
versioning scheme laid out by Till should work great. At some point we
may have a new major version of the SANE standard, which would imply a
soversion bump and also a new major release of the project.

I fully agree about backwards compatibility. Fortunately the API surface
of the SANE standard is small, so it's relatively easy to preserve the
compatibility.

Regards,
Povilas
> On Mon, Dec 27, 2021 at 5:10 PM Ralph Little <skelband at gmail.com
> <mailto:skelband at 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 <povilas at radix.lt
>     <mailto:povilas at 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"



More information about the sane-devel mailing list