Hi Grant, On 01/17/2008 at 7:51 AM, Grant Ingersoll wrote: > Our minor release cycles are currently in the 3-6 months range > and our major release cycles are in the 1-1.5 year range.
Since 2.0.0, including 2.3.0 - assuming it will be released in the next week or so - the minor release intervals will have averaged about 6.5 months, over three releases. Historically, the major release cycle intervals have roughly been: 1.0 - 6 months (March 2000 - October 2000) 2.0.0 - 6 years (October 2000 - May 2006) Six years is an incredibly long time to maintain backward compatibility. Assuming there will be a 2.4 release, and then 3.0 following it, it's pretty optimistic (IMHO) to think that it will be released before June 2008, so for 3.0, that would be: 3.0.0 - 2 years (May 2006 - May 2008) Two years doesn't seem so long in comparison :). > I think giving someone 4-8 (or whatever) months is more than > enough time to prepare for API changes. I am not sure how > this would effect Index changes, but I do think we should > KEEP our current index reading policy where possible. This > may mean that some deprecated items cannot be removed until > a major release and I think that is fine. Given the 6.5 month average minor release interval for the most recent major release, and the relatively low probability that this will shrink appreciably, you seem in essense to be advocating altogether abandoning backward API compatibility from one (minor) release to the next. However, below you are advocating a minimum of one "test balloon" release between incompatible changes: On 01/17/2008 at 3:41 PM, Grant Ingersoll wrote: > [N]o interface/deprecation changes would be done without announcing it > and there being at least one release in the meantime. Thus, if we > wanted to add isFancySchmancy() onto Fieldable today, it would have to > be announced, patch provided and referenced, a release without it (i.e. > 2.3) and then it would be available in 2.4. By ad-hoc, I meant that we > wouldn't just announce it and then have it show up in 2.3 and not give > people time to digest it. If I understand you correctly, a major release series could contain a whole series of non-aligned overlapping back-incompatible changes, since you are allowing individual features to alter backward incompatibility independently of other features. I think this is actually worse than just abandoning back-compatibility, since users would have to look up information on each individual feature to be able to figure out whether they can do a drop-in upgrade. Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
