|
From: Charles R. <cr...@ri...> - 2002-06-17 17:40:49
|
After some of the discussions we've been having about the release process, I'd like to suggest an approach to see if there's any feedback... Some key goals and issues: - We periodically want a "stable," beta-tested milestone that we can point to as a release for users who don't want to deal with bugs in new features. - We want to keep releasing development builds frequently for users who want to keep up with new features. - We have the ability to create CVS branches for stable releases (with no intention of merging them back with the main branch), expressly for disabling features which aren't ready for mainstream users yet. However, we don't want to duplicate bug fixes between stable branches and the main branch. In order for "stable releases" to make any sense, we need to have a period of beta-testing before a stable release. But since we don't want to duplicate bug fixes between branches, work during this period will need to be done on the main branch. This leads me to reject the idea of branches altogether, since the beta version should not include any (unstable) features that the stable version won't. Instead, James Sasitorn has suggested using periods of "feature freeze," where all development is focused on bug fixes until the stable release. (Perhaps if there is additional feature development underway already, the new features can be disabled in any beta/stable release.) The process would be as follows: - Prepare for a beta release by disabling any features not ready for mainstream users. - Announce a beta release by posting a "drjava-beta-DATE-TIME" build to the "DrJava Stable Releases" category on SourceForge and posting a news item requesting all users to download and use the beta version, looking for bugs. A "feature freeze" begins here. - For the next week, fix any bugs that come in. If we have time to work on new features as well, leave them disabled in any commit. - About a week after the beta release, create a "drjava-stable-DATE-TIME" build in the "DrJava Stable Releases" category on SourceForge and announce for all users. - Re-enable any new features that weren't in the stable release, and post a traditional "drjava-DATE-TIME" build to the (now-renamed) "DrJava Development Releases" category. - Continue working on new features until some arbitrary time when we decide to prepare another beta release. This approach would not use any CVS branches at all. It's also sort of subjective and arbirtrary for when we decide to do a stable release, but I guess that's ok. We should also make it clear that even development releases are usually very stable, but that users can expect to occasionally find bugs there with newer features. (This is the objective of full unit-testing, though of course it isn't perfect in practice.) Please let me know what you think. If there aren't any objections or additional suggestions, I'll plan on starting this process in the next few days, since we are currently at a convenient point to start a beta release. Charlie |