On 05/03/2008, Robert Schuster <theBohemian@xxxxxxx> wrote: > Hi. > > Andrew John Hughes schrieb: > > > It appears the property files for our tools are not being rolled > > into the release tarball. This fixes this. I'll put out a 0.97.1 > > release so distros also benefit. > > If there is going to be a bugfix release please add my StAX API patch > because this fixes a real compatibility issue and > does not change behavior. > > Regards > > Robert > > > I will roll that patch into the release too, hopefully this evening. We've not tended to generally do bugfix releases for GNU Classpath, although there have been exceptions. People will recall we rolled out a 0.96.1, and a while back, we jumped straight from one version to the next because of a significant bug. The policy has instead been that GNU Classpath is alpha quality, and so there isn't a concept of stable release branches. Is it worth changing this? Now that GNU Classpath has sufficient support to handle quite a few usecases (e.g. running Eclipse), should we maintain a separate stable release branch that fixes major bugs and regressions that come up post-release in a more timely fashion? My suggestion would be: * Keep to a regular series of new releases using the 0.x notation (I'll leave the whole 1.0 discussion for another time, but maybe we should just bite the bullet after 0.99). * Bundle appropriate bug/regression fixes into a stable 0.x.y release periodically in between. The criteria for such fixes would be that they don't add a feature or change behaviour that would be relied upon. With respect to 0.97 and the upcoming 0.97.1 release, the distribution issue and the STaX issue are eligible. Changes such as the addition of CPStringBuilder and the VM interface change are not. These are clear features that should be rolled out in a release. The less obvious case is a fix that makes GNU Classpath more compatible with the API or reference implementation but changes the behaviour from the 0.x.0 release. This should also be left until the next 0.x release. Thoughts, comments? I have no problem in maintaining such a release branch, given the current low traffic. If a patch should be considered for the branch, please include [release] in the subject line (as we used to do with [generics]) but obviously also commit this to mainline. Assuming people are happy with me doing so, I'll handle all commits to the release branch and reserve the right to reject it if the general consensus is against its addition. I'd be particularly be interested in hearing from those who package GNU Classpath for distros. Would this be advantageous? Or a major annoyance? Thanks, -- Andrew :-) Document Freedom Day - March 26th http://documentfreedom.org Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net
