[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)

[m. allan noah]

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 <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> 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20211227/2d227130/attachment.htm>