[DrJava] DrJava Stable Release Process

[Charles R. <cr...@ri...>]

   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