On Wed, 2008-09-24 at 14:34 +1200, Amos Jeffries wrote: > > Do we go from trunk to PRE or from trunk to DEVEL? I do not think trunk > > code is stable enough to be called PRE at this point, so I was expecting > > DEVEL. Personally, I would just call it 3.1.0 and categorize it as > > "development" on the web site until we can move it into the stable > > category (after a few 3.1.x releases). > > Before conn-pinning came up as an option I was thinking PRE. But it and > the other things destabilize enough to warrant a DEVEL period at least. > I'll decide after branching whether to release DEVEL, immediately or wait.
Please email RFCs before making the final decision about the labels and releases. Until we get to a stable stage, the labeling and timing of the releases should be discussed as it can benefit from what others have seen in their tests. For example, IMO, the trunk was/is not PRE-ready even after the recent fixes and before conn-pinning. In general, I think we should virtually always do at least one development release before a PRE. Jumping from trunk to PRE is much more likely to discredit the branch than a development-to-PRE delay. PRE, to me, means "we think it is stable, what do you think?". A development release, to me, means "we are done adding features, please help us with testing and polishing". And yes, I know that the definitions at http://www.squid-cache.org/Versions/ are somewhat different. IIRC, I failed to convince others that mine are better :-) > Concentration on the branch blockers then we can split and put the new > stuff and enhancements in trunk away from the hardening 3.1.x. > > Other important problems: > > http://www.squid-cache.org/bugs/show_bug.cgi?id=2459 > > http://www.squid-cache.org/bugs/show_bug.cgi?id=2460 > > > > I have asked somebody to work on these for the next 10 days, but I do > > not know if they will be able to fix them. I can work on them after > > eCAP. > > If they need a mentor I can probably assist in auditing 2459. Thank you, I will keep that in mind! > > Also, it would be nice to review and commit TCP_RESET propagation patch: > > http://www.squid-cache.org/bugs/show_bug.cgi?id=2042 > > > > Well, this is what the branch is for, so we can commit these 'nice' things > to trunk for 3.2 from 30Sept on and start their testing as well without > affecting the stability of 3.1. I meant that it would be nice to include RESET propagation in v3.1 not v3.2 :-). Not a big deal though. > The non-major but important bugs can be fixed during DEVEL and PRE > cycles. Branching is about features not bugs. Agreed, except I do not think we should have any known important bugs when doing the first PRE (if we do PRE at all). Thank you, Alex.
