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
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
