Andrew McIntyre wrote: > On 5/24/05, David Van Couvering <[EMAIL PROTECTED]> wrote: > >>I think the XML functionality will be of great interest to users, and >>they would like to play around with it. >> >>If there was a way we could document this as "experimental work" and >>were explicit about its level of maturity, this would be reasonable. >>I'm not sure what "support" means for an open source project... > > > Maybe it's just me, but I feel that, even for an open source project, > having an official release implies a certain level of code quality. If > Army doesn't think his code is going to be production-quality in the > timeframe of the release we're currently discussing, I think it should > be left out, even if it were to be undocumented.
I think it's more than just quality and in fact Army never says anything about "production quality". Looking at this for any feature, the issues (in order) for any suggested functionality are: 1) will a patch be ready in time for a release? Unless the functionality is the driving force behind a release, then a release should not be held up for a patch that doesn't exist yet. The release manager doesn't want to be endlessly delaying a release waiting for one or more contributors to submit or finish patches. Release early, release *often* means that such a patch can soon be in another release. 2) is the API to the functionality correct? Is this api (either Java classes, Jean Bean properties, SQL syntax, etc.) something that Derby should keep stable for some number of releases? This is probably the hardest issue to address, given that while Derby is open source and thus no guarantees are made, in order to be widely used the api's can not be changed every release. Though it may not be that any api has to be present forever, the user community can provide input to any api question, including removing an api. In some cases, like XML, it seems it would make sense to provide some warnings on the functionality indicating that they may change due to in-flux standards, but discussion about such future changes would need to include the user community. I don't want Derby to be in a position where it becomes hard to release functionality until we get it 100% perfect. 3) Is the quality good enough? I would hope that code committed in the trunk should be production quality, and this is enforced by * functional tests * code reviews * eyes on the code and the quality is further enhanced by getting the functionality into user's hands, allowing them to test it. (release *early*, release often). > And there are a couple of different ways for users to get access to > this new feature for testing: anyone interested in early access can > apply Army's patch to their view and try out the code once it is > available, or as soon as the release is done, we can put up a snapshot > of the latest trunk version that includes the XML support for users to > try out. Getting the functionality into a release will see wider use of it and thus lead to higher quality, due to the feedback. Other things to remember that we can always make subsequent 10.1 releases with bug fixes that improve the quality and that anyone can make a 10.2 release anytime after Andrew makes a 10.1 release. Dan.
