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
>
We could keep the so-version in each generation, that is also done in
CUPS and cups-filters. But then one could only add new features/symbols
on an increase of the second part and not remove anything. This reduces
the so-version bumps and the need to take care of compatibility here.
Till
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
Hi
I agree with this. Something I wanted to also propose.
Cheers
Ralph
On Mon, Dec 27, 2021, 13:04 Povilas Kanapickas 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
Good idea, exactly what I do with cups-filters. I also started as you
are doing currently, 1.0.xx and every time increasing xx independent
whether I have a feature release or bug fix release.
Then I realized the meaningless 2 first components and the ridiculously
increasing third component
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
