Hi all, While I agree that 3 months is a tight schedule for all the quality checking work etc, I think there would be very big danger of slowing down the development and lower quality of the products, if the release schedule would be longer than 3 months.
Clytie: you already found the solution: you do not have to QA every release. QA only those releases that fit to your schedule. All this comes down to size of the codebase (complexity) and the amount of changes (fastness). OpenOffice.org is one of the big open source codebases. It is not as big as Linux kernel, but it is bigger than Mozilla. Kernels are released about EVERY TWO MONTHS. And there is very good reason for it: in just two months, the kernel has already changed more than many other products/projects in a year or two. Also OpenOffice.org gets lot's of changes in every month. In order to MAINTAIN good quality of the codebase, it is very important to release quality-controlled releases often. Otherwise too many bugs would not be noticed. Look at this: - OOo 2.1 : 2 months of development, the last 1 month of focused QA - OOo 1.1: 4 months of development -> Beta1, + two months -> Beta 2 +five months -> Release = 7 months QA (!) Longer development cycles are just not acceptable. If QA time is more than 1 month, there will be lot's of new code in the non-stable development branch, that will get bad quality, because everyone is concentrating in QA:ing the stable release. So after the release is done, then there will already be a bad quality development release to work with. .... Frequent time-based releases are good: you know when there will be a release. You can plan your work according to that. When you plan, don't do: "I want to get all my features to next release" You should do: "Well, there's release X in 3 months, Y release in 6 months and release Z in 9 months. If I work on this issue C for two months, I can get it to release X. The issues A and B take more time, so I'll target release Z for them." ... We cannot make the schedule fit everybody's needs. You have to adapt to the schedule. Clytie is a good example of a project (vi lang) that has just started - there's lot's of work and few people. It is understandable if only some releases are QA:d. Or that one does not do full QA until later time ---> only release "Alpha"s or "Beta"s. On the other hand, there are languages that have already been working for a long time and have bigger amounts of participants. For them it is much smaller task to fix a few added/modified translations and some other issues. It is not fair to make them wait half a year. It is not the open source mentality to make "perfect" releases that contain "everything". The open source mentality is to release incrementally BETTER releases OFTEN. This is especially the situation when the codebase is big and complex and when there are lot's and lot's of people making changes. .... Make your own plans according to your own resources, but DO NOT FORCE your schedule on every else. The others have their own schedules to worry about. It is not possible to make everybody's schedules fit together. It would just result in the worst case: the lowest common denominator - http://joelonsoftware.com/items/2006/11/21.html, with the view from the other side: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html Mox
