[squid-dev] [RFC] Squid 4.0 ideas

[Amos Jeffries]

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.

There is approximately 8-18 months "year" between series releases now. A
very arbitrary choice whenever it seems reasonable to release a batch of
features. My undertanding of the proposal stated was that we keep that
current practice, but dropping the 2-part "3.x" numeric down to a single
part.


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

 ... last month we had non-trivial feature changes (100+ Lines of code)
on the 26th, 22nd, and some lesser (25+ LOC) but still widely user
visible new thing on the 11th and 1st, and large-ish but not user
visible feature changes across the 1st-5th and 19th.
 That would be 4-8 major releases of Squid within the month of Feb 2015.

> 
> 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. Roughly because
it is +/- a few years and the next "new" language this time around can
build anything 3.3+ AFAIK, while the "old" language can't build new
tarballs - and there is precedence in the last changover there too with
C++ tools building C code fine but _not_ vice-versa.

I'm seeking opinions. On whether we continue with that pattern in
conjunction with the coming trunk activity, or discard it in favour of
something else - even if that something else is slipping down the slope
towards an eventual 3.999 series (haven't heard anyone advocating for
that though).

> 
> 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.
> 

Thank you for the feedback.

Amos