[Privoxy-devel] Changing the Privoxy version number scheme

[Ian Silvester]

Hi all,

I'll admit that I can see the advantage of both approaches, but on balance I like the idea of sticking with 'classic' version numbering for the reasons you enumerate Roland, plus the fact that they are more 'user friendly' for non-technical users. I also like the idea of bumping to the next major release digit at this point. Yes the numbering scheme is arbitrary, but it is simple.

By the by, one item to include in the release notes will be HTTPS inspection support for macOS - just this morning I had confirmation from my UAT tester.

Cheers,

Ian



On Tue, 3 Jan 2023, at 16:00, Roland Rosenfeld wrote:
> Hi!
>
> On Di, 03 Jan 2023, Fabian Keil wrote:
>
>> I'd like to change the Privoxy version number scheme after
>> the 3.0.34 release.
>> 
>> At the moment the Privoxy version numbers look like they
>> might follow the semantic versioning scheme [0] but actually
>> we just bump the last number at each release even if
>> there are incompatible changes.
>>
>> In the past we used even last numbers for stable releases
>> and uneven numbers for beta releases but we stopped releasing
>> beta versions as they weren't properly tested by users or
>> picked up by distributions.
>
> From this perspective we could get rid of one component and continue
> with 3.1, 3.2,...
> Since my intuition says, that 3.0.34 sounds bigger than 3.1, it may be
> a good idea to skip 3.1 and continue with 4.0, 4.1,... instead.
>
>> Another problem with the current scheme is that it doesn't
>> work when updating binary packages. For example it might make
>> sense to release new Windows packages when there's a MbedTLS
>> vulnerability but at the moment it's not clear what kind
>> of version to use for such an update.
>
> For this use case we could (temporarily) add another component, so the
> re-build(s) version of 4.3 would be 4.3.1, 4.3.2,...
> while the next regular release is 4.4.
>
>> For my own projects I nowadays usually just use a date
>> as the version number followed by a git hash. For example
>> the last zogftw [1] release is 2022-06-25-03982c7.
>>
>> This is easy to automate but one downside is that it's not
>> obvious how many releases occurred between two releases.
>> I'm not sure how important this is, though.
>> 
>> Any opinions about this?
>
> To say the truth, I personally don't like versions like this very
> much.  From my point of view there are several drawbacks:
> - The version string is ugly long.
> - The hash isn't sortable (if there are multiple commits per day).
> - You cannot enter the version number to the Changelog, since the hash
>   isn't calculated before the final commit that writes to the
>   Changelog.
> - There still is no canonical way how to number a binary package
>   update (see above).
> - And last but not least the psychological factor: If an release is
>   date is one or two years ago, it looks "old".  Additionally Debian
>   releases about every 2 years.  For example the current stable
>   release in Debian is 3.0.32 (from 2021-02-xx), which sounds quite
>   old, but is only one point release older than current 3.0.33.
> - I don't think that this is much easier to automate, since the
>   autoconf/manual/... stuff has still to be rebuild with the version
>   number changed and this shouldn't be "today" (in the sense of build
>   date), but it has to be ha fixed date string from the release date.
>
> So I'd suggest switching from 3.0.34 to 4.0, 4.1,... and if there is
> some major update sometimes, we can switch over to 5.0,...
>
> Greetings
> Roland
>
> _______________________________________________
> Privoxy-devel mailing list
> Privoxy-devel at lists.privoxy.org
> https://lists.privoxy.org/mailman/listinfo/privoxy-devel
>
> Attachments:
> * signature.asc