[squid-dev] [RFC] Squid 4.0 ideas

Henrik Nordström henrik at henriknordstrom.net
Fri Mar 13 09:42:07 UTC 2015


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




More information about the squid-dev mailing list