[ http://issues.apache.org/jira/browse/DERBY-1547?page=comments#action_12428400 ] V.Narayanan commented on DERBY-1547: ------------------------------------
Hi, Thanx for taking time to look at the issue and offering guidance. In relation to the suggestion for having a property file containing the version along with the subversion number which gets updated each time we build tests pls consider the following scenario and the questions that follow. SCENARIO DESCRIPTION -------------------- 1) I do a svn update on an workspace and get a suversion version as X. 2) Now I do an ant all && ant buildjarsclean 3) Now I have another workspace on which I do an svn update and get subversion number X+1. I do an ant all && ant buildjarsclean on this (or) I use the same workspace and do an svn update and get svn version X+1. I do an ant testing && ant buildjarsclean on this. In both of the above cases we would have the properties file having a subversion number as X+1. 4) To run tests I use the combination of derby.jar from 2) and derbyTesting.jar from 3). QUESTIONS RELATED TO THIS SCENARIO ---------------------------------- 1) Is the above scenario valid? 2) Is it right to expect the user to do an svn all each time he runs tests as expected of him in the above case? > Add svn version number to DatabaseMetaData getDatabaseProductVersion and > getDriverVersion() to improve supportability > ----------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-1547 > URL: http://issues.apache.org/jira/browse/DERBY-1547 > Project: Derby > Issue Type: Improvement > Components: JDBC > Affects Versions: 10.1.3.2 > Reporter: Kathey Marsden > Assigned To: V.Narayanan > Priority: Minor > Fix For: 10.2.0.0 > > Attachments: DERBY-1547_v1.diff, DERBY-1547_v1.stat > > > getDatabaseProductVersion and getDriverVersion() report only the four digit > Derby version number and not the svn build number. It would be useful to > return the full version including the build number as sysinfo does: e.g. > "10.1.2.4 - (392472)", That way it will be clear from application logs that > collect this information exactly what revision level they are running if they > are using rolled up fixes on the maintenance branch between releases. > There may be risk in doing this however if applications are parsing the > version information, but hopefully they will use getDatabaseMajorVersion() , > getDatbaseMinorVersion, getDriverMajorVersion, and getDriverMinorVersion for > such proccessing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
