On 4/24/13 3:48 AM, Knut Anders Hatlen wrote:
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,
Right. I think this migration of methods would have to happen in order
to compile the JDBC 3 datasources with the Java 6 compiler. The JDBC4
variants would be vacuous extensions of the JDBC 3 versions.
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.
Originally, I thought that we would just remove the JDBC 3 versions of
the classes from the javadoc. This involves the following:
i) Adjust the publishedapi build target to only build one version of the
public api javadoc
ii) Adjust the documentation page to point directly at one version of
the public api rather than at an intermediate level which switches
between jdbc3 and jdbc4
iii) Adjust the top level index.html in the release distribution so that
the "Using Derby" section points at only one set of public api javadoc,
not two.
As we talk through this, I'm now thinking that we could just as easily
get rid of the jdbc4 version of the javadoc and keep the jdbc3 javadoc.
For backward compatibility reasons, we wouldn't remove the jdbc4 classes
from the product. But since they would be vacuous, I don't see any need
to document them. Going forward, users would be encouraged to create an
instance of EmbeddedDataSource rather than its vacuous extension,
EmbeddedDataSource40.
Thanks,
-Rick
