[Privoxy-devel] Changing the Privoxy version number scheme

[Roland Rosenfeld]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.privoxy.org/pipermail/privoxy-devel/attachments/20230103/78a16797/attachment.bin>