Adrian Chadd wrote:
2008/6/25 Henrik Nordstrom <[EMAIL PROTECTED]>:
We should be using "release often" strategy, which means making a new
release whenever sufficient amount of new features or stable
restructuring of code is completed. In such strategy road maps is merely
a wish list, what actually gets into the release is a matter of what
really gets done, not whats on the roadmap. I am fine with seeing 3.2
released when the log daemon stuff is done, even if it means a lot of
the things currently on the roadmap for 3.2 gets pushed to 3.3.
I completely agree. Thats one of the things which Squid hasn't been
doing and I've been pushing in Cacheboy.
It's not a good idea to hold up releases or commits of other tested
features unless one is waiting for a change which is in the very final
stages of testing.
Assigning version numbers to not yet ready features is really no more
than stating an intended priority. May I propose that we use priorities
instead of release numbers in the road map, resulting in a roadmap which
looks more like
[snip]
Priorities are fine, but having some actual long-term directions to
fit these features into a roadmap will make much more sense.
Personally, I think you guys should consider fixing or reverting
whatever stuff is in Squid-3.HEAD right this second which causes
instability and release Squid-3.1.
:-) Oh I'd love too...
There's nothing in there right now thats inherently unstable (excepting
ESI and COSS from 3.0). Just a few bugs on the high-priority track.
The holdup is us still sticking with the deadline-based management we
implemented in the last round of Adrian-negotiations if you recall.
Amos
--
Please use Squid 2.7.STABLE3 or 3.0.STABLE7
