[squid-dev] [RFC] Squid 4.0 ideas

[Alex Rousskov]

On 03/07/2015 10:04 PM, Amos Jeffries wrote:

> Proposal 2)
> 
> We are developing Squid with an incremental development process. The
> initial major version number is effectively meaningless in that process.
> We should move from the major.minor.patch to just a release.patch
> numbering system.
> 
> This would mean this years upcoming major series would be 4.x, and next
> years would be 5.x and so on.

My understanding of what has been proposed as release.patch is
different: There is no artificial year boundary. If you add something
new, you increment the release (i.e., first) number. If you just fix
something old, you increment the patch (i.e., second) number.

The advantage is in removing a concept of a "major release" and the
often artificial boundaries associated with it. For example, you would
not have to search for an excuse to release 4.0 like you are doing now.

The disadvantage is in removing a concept of "major upgrade pains" and
the often real boundaries associated with it. For example, it would be
more difficult for you to explain that jumping from 11.4 to 12.4
requires a week of system administration and testing work while going
from 11.4 to 21.4 does not.

You can still have LTS-like releases, of course. The versioning scheme
does not affect that at all.


> There are quite a lot of infrastructure changes involved with that big a
> change, and its not entirely clear how the beta releases would be
> represented - perhapse not having any beta releases at all?

As Kinkie have said, you can apply the current solution for beta
releases by adding an extra number after zero. For the release.patch
scheme, betas would look like release.0.patch.

I remain to be skeptical about the advertised correlation between our
initial stable releases and actual, real-world stability. Our official
beta process seems to mislead as much as it informs. Thus, I welcome
experiments that would get rid of that process.

At the end of the day, versioning does not really matter much IMO. The
important things are stability and timeliness (i.e., release delay for
features in trunk) of our releases.


HTH,

Alex.