Myrna van Lunteren <[email protected]> writes: > I've not replied before, mostly because I am torn a little... > > On the one hand, I am fed up with supporting the CDC platform that > has little interest, 1.5 is getting harder to support too. > > On the other hand, I expect backports to older versions that I have > to support being harder the more trunk changes. The recent cleaning > up of suspicious and messy code might already make things > harder...But I think moving forward is important too, and cleaning up > "bad" or inefficient code might improve supportability in the > future...
My feeling is that we pay most of that back-porting tax already, only that it's hidden in the cost of fixing it on trunk, because trunk needs to be portable to old platforms. Currently, we develop patches against trunk, most likely using a fairly recent JDK. Then we find that it has broken something in the nightly tests on an old platform because we've used a method or class that's not available, and we go back and fix that on trunk. After this, back-porting is essentially free. If we drop support for some platforms on trunk, we move the extra cost of getting it to run on old platforms from development to back-porting. The total cost of developing a fix and back-porting it should be roughly the same, though. And for the code that's not meant for back-porting, we avoid that tax altogether. > I don't mind striving for a support of current jvm -2. However, in > the future there might be compelling reasons to deviate, so I am > hesitant to pin things down. I'd be fine with deciding this on a case-by-case basis rather than having strict rules. > How would you remove the jdbc3 javadoc without removing support? I guess we can move the JDBC 4 methods to the JDBC 3 data sources (if I recall correctly, we have moved most of them already, only getParentLogger() is missing), so that they both support JDBC 4, and then make the (former) JDBC 3 versions of the classes visible alongside the JDBC 4 classes. I think the rationale for splitting them in the first place, was that if we had just a single version of the javadoc, it would tell lies about the JDBC 3 versions of the classes (for example since EmbeddedDataSource is a non-abstract class implementing java.sql.DataSource, the javadoc tool thought it implemented all JDBC 4 methods). When all the data source classes do support all JDBC 4 methods, it's no longer a lie, so we can re-introduce EmbeddedDataSource and friends in the JDBC 4 version of the javadoc. -- Knut Anders
