[squid-dev] [RFC] Squid 4.0 ideas

[Alex Rousskov]

On 03/10/2015 04:58 AM, Amos Jeffries wrote:
> On 10/03/2015 5:41 a.m., Alex Rousskov wrote:
>> 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.


> Its already clear from past discussions that our views of "feature" are
> very different. If we bumped the version with each "new thing"  ...

I did not say "each". Squid releases happen when you make them happen,
and I am not discussing release timing. I am only talking about how to
number the releases. The release.patch algorithm is simple: If you
decide to make a release containing at least one new feature, increment
the release counter. Otherwise, just increment the patch level.


>> 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.
> 
> I'm not searching for excuses. There is a meta-pattern of previous major
> numbers changing roughly when the language is changed.

There is no such pattern IMO. There is just one historical case that
fits the alleged pattern (v2->v3). Before v3 (v0, v1, and v2), Squid was
written in C. Since v3, Squid is written in C++. You may, of course, try
to establish such a pattern for future major releases.

AFAIK, nobody has strong objections either way -- version numbers are
not very important. I am just trying to document how the simpler
(release.patch) numbering may work and what its advantages/disadvantages
are.


HTH,

Alex.