If we follow Chris's logic that the trunk is good enough for a beta, then hopefully we can move this stabilising effort to trunk instead of branches, and only back port as the exception. I guess the problem is that users find issues on stable branches - though in most products they expect to wait for the next release for a fix, and occasionally get a patch for a current release. Maybe we can make our lives easier by toning down expectations of branch maintenance a notch, in favour of optimising stability of the trunk.
This has always been the policy of GeoServer. Not so on GeoTools. But on GeoServer trunk has always received the bulk of the stabilizing effort. Stable branches have tended to not go off of trunk until RC's at the earliest, often waiting for the .0 release. Mostly because it's such a pain to maintain two at once. The trunk of 1.4.x became a stable branch when 1.4.0 to RC status. Trunk of 1.3.x became a stable branch after 1.3.2 went out. Trunk for 1.2.x became a stable branch after 1.2.3 went out. 1.1.x was made right before 1.1.1.
1.5.x was made a stable branch in the beginning of December, and I was under the impression that we were only several weeks away from 1.5.0. This has obviously not been the case. And the timings have been screwed up because Justin's work was complete and needed to come online.
Still, a beta tends to imply a focus of testing effort. It doesnt feel right to release a stable branch as a beta and the trunk too. Perhaps we should release a beta from trunk when the last release hits final? And alphas up until then ?
Stable branch just hit release candidate. So it feels right to make a beta for me. I agree it didn't feel right before then. `I concede we shouldn't go beta right now, since GeoTools changes aren't working right on their trunk. But from a GeoServer perspective it really should be a beta - it's pretty much all the same code in 1.5.0, with improvements for WFS and dispatching.
To some extent this is a matter of semantics, beta and alpha only mean anything within a certain scope. In GeoServer, however, alpha has only been used twice since 1.0, and both times meant that only a programmer could handle them. To me 'beta' means that a user will be able to successfully install it, and the majority of the code _should_ be working, it's worked for programmers, but we make no promises. We put betas out in the hope of getting feedback. I believe this is pretty standard across other open source projects. In light of this I don't think it makes sense to switch our policy to start calling these alphas. If people would like I can write up a document summarizing this.
Chris
Rob A
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1003,45d22e39220971365099012!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
)developers