On ons, 2008-06-25 at 16:34 +1200, Amos Jeffries wrote: > I definitely need to see it operating in some 3.1 release (for > commercial reasons). If there are no objections I'd like to move it from > the initial release list, but reserve the commit to a later release of > 3.1. So that its no longer considered a blocking feature.
It's a fairly big change and certainly not something I would consider a bugfix. It adds both squid.conf directives and a new daemon, which means it has considerable impact for both users and packagers. 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. 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 - Things that have been completed. - Things currently being worked on. Including things which have been contracted to get done but not yet started. - Estimated date of the next release currently being worked on. - A general rule of thumb that new releases is normally done in N-M months after the previous release, but depends on the development being done. - Priority sorted list of things we'd like to see get done. Each item in these lists with their own wiki feature page.. Regards Henrik
signature.asc
Description: This is a digitally signed message part
