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
|
