[squid-dev] [RFC] Squid 4.0 ideas

[Amos Jeffries]

On 20/10/2014 10:38 a.m., Amos Jeffries wrote:
> Kinkie brought up the idea of a Squid 4.x release in IRC.
> 
> I have mentioned to a few clients who asked when 4.0 would be out that
> we will probably want it to be a big reason, like changing the
> language was between the 2.x to 3.x versions.
> 
> I have usually had in mind a change along the lines of:
>  - libraries building with Erlang/Ada/Go, or
>  - redesigning the whole packaging structure (but we already have
> SourceLayout without it), or
>  - redesigning the event processing system (but we already did
> AsyncJob without it).
> 
> Then again, we actually *are* planning a language change in the next
> few months.
> 

Proposal 1)

> The C++03 to C++11 transition will bring with it a relatively large
> bump in the minimum toolchain and thus OS support. So while it's not a
> radical change it is probably worth considering as a good reason for
> calling the next series 4.0.
> 
> If we do so we would also need to treat 3.5 as somewhat of an LTE

(Sorry thats a typo, I meant LTS - Long Term Supported. With most of the
support being by the distro maintainers, but upstream accepting compiler
support patches in addition to security fixes in its EOL period)

> release. That was on the cards anyway for older OS with backports
> having the same criteria of building on C++03 compilers. The version
> bump would make it somewhat formal though with us needing to take on
> the maintenance instead of punting it off to commercial or distro
> support teams. Are we prepared as a group to go for that?



The Foundation board has had a bit of discussion about this proposal
during the last meeting and countered with a different proposal for
consideration. Otherwise are split over whether to change at all, and
with good reasons on all sides of he decision.


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.

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?


If the issue of betas can be resolved in a good way I am inclined to go
with proposal #2 myself. Lacking that with proposal #1.



We still have a few months to think about this before a final call is
made. All ideas and opinions welcome.

Amos