[squid-dev] [RFC] Squid 4.0 ideas

[Eliezer Croitoru]

Just couple notes from me.

One feature or more can be considered a good reason for a new version.
If we aim for the enterprise level users\admins then some if not most of 
them would like to run a stable feature\version.

The state of squid now is very good compared to v2->v3.
Maybe it's not the "time" to change a language but the question I must 
raise is:
How much do we want to improve the current code? how much more stable do 
we need\want it to be?

Just adding that the current path squid has taken until now leads to 
state which the OS reports a golang helper requires 300-400 MB of 
virtual memory while squid for the same run-time and much more complex 
computation actually uses 120MB+- of resident memory and about 20MB+- of 
virtual memory(in some cases).
So squid is on the right path until now(to my opinion) and one or 
another way of "counting" the code advancements should take in account 
mainly the stability of the software.

Eliezer

On 13/03/2015 11:42, Henrik Nordström wrote:
> tis 2015-03-10 klockan 23:58 +1300 skrev Amos Jeffries:
>
>> 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.
>
> Yes, except that we should aim in decreasing release cycle a bit. 18
> months is not acceptable. imho 6-12 months is a more reasonable cycle.
> Only longer if there have been no meaningful new features matured in
> last 6-10 months.
>
>> Its already clear from past discussions that our views of "feature" are
>> very different. If we bumped the version with each "new thing"  ...
>
> patch releases should be just patch releases. No config changes unless
> absolutely required due to security issue.
>
> version number is bumped after each release with new features. Whatever
> features gets finished & tested in time gets included in next release.
>
> One new feature is sufficient for a new release if we want. There should
> be no need to wait for other features to finish testing.
>
> Some features likely will need several releases before becoming user
> visible, where infrastructure plumbing goes into the first one or two
> releases before feature is ready.
>
>>   ... 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.
>
> There is obviously no need to increase version in trunk/master for every
> change, just every release we make with new features compared to
> previous release.
>
>> 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.
>
> The compiler & library requirements is continuously increased slowly,
> and is fully acceptable as long as we stay within our supported range of
> operating systems. No need for a major version to indicate this.
>
> The Squid-2 -> Squid-3 bump was a major rewrite over many years. In many
> ways a failed project. Lets not repeat that.
>
> The development model that works for us is incremental development model
> in smallish steps. I argue that we are not in a position to take on
> another major rewrite.
>
>> 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).
>
> I am advocating for 1234.5.
>
> Regards
> Henrik
>
>
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>