On 30 November I posted some Rough Code Guidelines to this list. In the light of some of the posts, I think I ought to expand and clarify some issues to avoid any obstacles to further development of the code.
There are currently three main developments being led by our Project: 1. Mark Tutt's new codebase as he described it recently in his post here and in the forums in the past. 2. Efforts to modularise and rework the current codebase to overhaul JDBC and other functionality. These are mainly led by Campbell but recently we had contributions from Hiep and Clay. 3. Efforts to fix the bugs and improve SQL and JDBC compliance in small areas. These are led by myself based on contributions from many users and developers. Mauricio will be helping to ensure JDK 1.1.x compliance and hopefully contribute code as well. I am discussing mainly the 3rd group of efforts below: Mauricio correctly pointed out the following: --quote Just keep in mind while writing the proposal that the current HSQLDB is not really a GNU-type project, where you are forced to contribute changes back to the community. I understand from looking at the forum posts that many developers use this code as part of a larger commercial project, and there has to be a way for them to contribute changes back to the community if they desire to do so. ---end quote The above has always been a main consideration in the development and maintenance of the Hypersonic into HSQLDB code. Implication 3.1: Changes to code base will be made in the CVS in incremental steps to allow outside developers to reincorporate their changes into the code base and hopefully contribute them back to the Project. Implication 3.2: If possible, changes to SQL /JDBC should be linked to entries in the properties file which allows at least some backward compatibility with previous versions. This applies where there are two different valid interpretation of the same features. (there are already examples of this, see patch 491272 for instance). This clarifies my stipulation in the Rough Code Guidelines that: "Improvements to SQL and JDBC interfaces should bring HSQLDB closer to common standards. Clear notification should be given when improvements _might_cause incompatibilities with existing applications that use HSQLDB. This area is very important and needs special attention." Regarding the 2nd group of efforts: Implication 2.1: If we are going to use the CVS regularly we need to have a structure in the CVS for the inclusion of those contributions as they are being developed. For example, Clay has recently made some contributions with the aim of changing the existing code to support multiple database and different transaction isolation levels. His effort needs a lot of development and testing before they become part of a release. In the meantime, group 3 changes would be introduced regularly and accepted or rejected in a shorter time-frame -- we need to establish procedures to do both at the same time. Implication 2.2: We need to modularise more as we go along. There are two completely different uses of HSQLDB as applet and application / server which have different size implications. We need to be able to build both out of the code base, keeping 1.1.x and 1.2.x and above compatibility for both. I will later release the Rough Guideline together with the contents of this post on the web site. Fred Toussi _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
