db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fuzzylo...@apache.org
Subject svn commit: r125729 - /incubator/derby/code/trunk/STATUS
Date Thu, 20 Jan 2005 07:09:35 GMT
Author: fuzzylogic
Date: Wed Jan 19 23:09:11 2005
New Revision: 125729

URL: http://svn.apache.org/viewcvs?view=rev&rev=125729
Log:
Update STATUS.

Modified:
   incubator/derby/code/trunk/STATUS

Modified: incubator/derby/code/trunk/STATUS
Url: http://svn.apache.org/viewcvs/incubator/derby/code/trunk/STATUS?view=diff&rev=125729&p1=incubator/derby/code/trunk/STATUS&r1=125728&p2=incubator/derby/code/trunk/STATUS&r2=125729
==============================================================================
--- incubator/derby/code/trunk/STATUS	(original)
+++ incubator/derby/code/trunk/STATUS	Wed Jan 19 23:09:11 2005
@@ -109,9 +109,7 @@
 
 Releases:
 
-The first release, versioned 10.0.2.1, was announced on December 8, 2005.
-See
-http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=derby-user@db.apache.org&msgNo=284
.
+    * 10.0.2.1 released on December 8, 2005.
 
 PENDING ISSUES
 ==============
@@ -131,185 +129,61 @@
 RESOLVED ISSUES SINCE LAST STATUS
 =================================
 
-[VOTE] on repository layout:
+[VOTE] Network Server XAMGR Level Support
 
-   [ Ten votes ]  Option 1: Keep the code and site pages in
-                  separately-versionable trees (
-                  derby/site/{trunk,tags,branches}/<pages> and
-                  derby/code/{t,t,b}<code> )
-   
-   [ One vote ]   Option 2: Put all things Derby into a single tree
-                  ( derby/{trunk,tags,branches}/{<code>,<pages>} )
-
-
-[VOTE] Establish development model based on Apache DB guidelines
-
-  Derby is being sponsored by the Apache DB project and the Derby
-  status page states 'The Apache DB project will own the Derby
-  subproject, and the subproject will follow the Apache DB PMC's
-  direction'.  (http://incubator.apache.org/projects/derby.html)
-  
-  A vote was proposed that the Derby development model follows the
-  guidelines defined by the Apache DB project. This will set the
-  initial rules for development, changes to the model could
-  subsequently be called for and voted on using the Derby developer
-  mailing list.
-  
-  The guidelines are defined at http://db.apache.org/guidelines.html
-  
-  There is one difference that the Derby code is in SVN and not CVS.
-  
-  Note the decision making page at http://db.apache.org/decisions.html
-  and the Changes section on this page
-  http://db.apache.org/source.html.
-  
-  The Changes section indicates the commit model is:
-  
-  (quote)
-  
-  Simple patches to fix bugs can be committed then reviewed. With a
-  commit-then-review process, the Committer is trusted to have a high
-  degree of confidence in the change.
-  
-  Doubtful changes, new features, and large scale overhauls need to be
-  discussed before committing them into the repository. Any change
-  that affects the semantics of an existing API function, the size of
-  the program, configuration data formats, or other major areas must
-  receive consensus approval before being committed.
-  
-  (end-quote)
-  
-  Result: Six +1 votes.
-
-
-[VOTE] Derby upgrade policy
-
-  A vote was proposed to accept that for any release of Derby the
-  upgrade policy described in:
-
-  http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby-dev@db.apache.org&msgNo=77
-
-  is followed.
-
-  The summary is that any release of Derby can run against a database
-  created by a previous release with either no upgrade, soft upgrade
-  or hard upgrade mode, depending on the circumstance.
-  
-  This would mean that if some new feature was added to Derby, before
-  a release occurred the correct upgrade code would have to be
-  written, if the feature contributor did not provide it.
-  
-  Result: Three +1 votes.
-
-
-[VOTE] Derby versioning:
-  
-  A vote was proposed related to the Derby upgrade policy vote.
-  
-  That the version scheme currently in place, and described in:
-  
-  http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby-dev@db.apache.org&msgNo=73
-  
-  be accepted in order to facilitate the upgrade policy voted on and
-  accepted in the Derby upgrade policy thread. As such, Derby versions
-  should take the following form: MAJOR.Minor.interim.point {beta}
-  (build identifier). As an example, the currently posted snapshot
-  version of Derby is 10.0.2.0 (46005).
-  
-  Whereby:
-  
-  Differences in the major version are used to identify large changes
-  in architecture and functionality, and for which upgrade is
-  required.  Differences in the minor version are used to identify
-  changes in functionality large enough to require an upgrade
-  procedure for databases from the previous version, and for which
-  upgrade is required.  Differences in the interim version are used to
-  identify significant differences in behavior of the database engine
-  from the previous interim version, but for which upgrade to
-  databases is not required.  Differences in the point version are
-  used to identify that any amount of change to the database engine
-  has occurred from the previously released point version.
-
-  That the build identifier be used to distinguish the exact state of
-  the code from which any specific set of binaries have been compiled,
-  That the beta flag in the version denote that the upgrade policy is
-  in an indeterminate state with respect to the previous version and,
-  as such, that an upgrade to a beta version of Derby is allowed, but
-  an upgrade from a beta version of Derby to any other version of
-  Derby is not allowed.
-  
-  I would like to further propose that, following that version scheme,
-  that releases from any branch have a specific version number and be
-  tagged in the repository. Thus, following this version scheme, the
-  forthcoming baseline release of Derby should be versioned 10.0.2.1,
-  as it includes changes which are not included in the first public
-  version of the source. Once the release is ready, the version on the
-  trunk will be changed to 10.0.2.1 and then tagged in subversion.
-  
-  I would like to also further propose that before changes which would
-  require upgrade are allowed into the trunk, that the trunk be
-  branched, so that the branch can serve as the reference for the
-  upgrade policy.  After branching, the minor (and/or major) version
-  of the trunk will be incremented, and the beta tag applied to
-  indicate that significant changes exist in the trunk which would
-  require database upgrade and that the code for performing the
-  upgrade has not been rigorously tested. As an example, before a
-  change could be applied which would require upgrade, a new 10.0
-  branch would be created and the trunk would be reversioned 10.1.0.0
-  beta, in order to distinguish the trunk from the new branch and to
-  allow changes that require a database upgrade into the trunk.
-  
-  Result: Three +1 votes. Passed.
-
-  
-[VOTE] Re: Help detecting client disconnects for network server  
-
-  Kathey Marsden proposed the following vote concerning the use of TCP
-  keepalive for Network Server:
-  
-  1) Have keepAlive on by default. It seems important not only for
-  locks but for potential network server bloat due to connections not
-  getting cleaned up.  Result: Three +1 votes. Passed.
-  
-  2) Add a property derby.drda.keepAlive={true|false} (defaults to
-  true as described above).  There seems to be a need to be able to
-  turn keepAlive off in some cases.  Result: Two +1 votes, no
-  objections. Passed.
-
-  3) Add property derby.drda.connSoTimeout=<milliseconds> (defaults to
-  0, infinite) to provide the ability to have connections timeout
-  after a period of inactivity. The connections will still timeout,
-  even if the connection is working fine but will timeout after
-  blocking on a read for this length of time.  I am about +.5 on this
-  one.  It would be nice to provide the capability, but hesitate to
-  add yet another property.  Result: One +1 vote, objections
-  noted. Not passed.
-  
-
-Copyright issues with the Derby codebase
-
-  There were concerns over how the IBM copyright notices attached to
-  the Derby source files were to be retained, if at all. For the
-  discussion of the concerns surrounding this issue, please see:
+  Kathey Marsden submitted a patch for adding XA Support to the Network 
+  Server. It received three +1 votes, and was committed as revision 123827
+  to the trunk.
+
+[VOTE] Intersect and Except
 
-  http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby-dev@db.apache.org&msgId=1885981
+  Jack Klebanoff submitted a patch adding support for SQL INTERSECT and EXCEPT
+  The patch received four +1 votes and was committed to the trunk as revision
+  124467.
 
-  and the thread concerning the resolution of this issue:
+[VOTE] Java routine signature support - Derby 89
 
-  http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby-dev@db.apache.org&msgId=1968757
+  Jeremy Boynes submitted a patch that is a first step to adding Java method
+  signature support for Java routines. The patch received one +1 vote, and
+  no vetoes, so the patch was committed to the trunk as revision 124819.
 
+[VOTE] JDBC 2.0 Updatable Result Sets
+
+  Mamta Satoor submitted a patch to support the delete functionality of JDBC
+  2.0 Updatable Result Sets. After some discussion, the patch was committed
+  as revision 125266 to the trunk.
 
 OTHER NEWS
 ==========
 
-  Bug tracking has been set up at http://issues.apache.org/jira/browse/DERBY 
+A branch has been created based on the 10.0.2.1 release. To check out the
+branch, use the following Subversion URL:
 
+svn co http://svn.apache.org/repos/asf/incubator/derby/code/branches/10.0
 
+The Derby trunk is now versioned 10.1.0.0 alpha. The trunk is not suitable
+for production use. Please see the warning at 
+http://incubator.apache.org/derby/derby_downloads.html in the "Derby source
+code" section.
+
+The Derby Code contest at ApacheCon received several entries. Details on the
+entries and winners can be found here:
+
+http://mail-archives.apache.org/eyebrowse/ReadMsg?listName=derby-dev@db.apache.org&msgId=2006536
+
+Kathy Saunders announced that IBM would contribute a new Derby Network
+Server client driver to Derby, to replace the need to use the IBM 
+Universal JDBC Driver, or JCC, to connect to Derby Network Server.
+Since the last update to STATUS, tests, scripts, and demo applications for
+Derby have also been contributed.
+
 RELEASE STATUS
 ==============
 
-The first release, versioned 10.0.2.1, was announced on December 8,
+The first release, versioned 10.0.2.1, was announced on December 8,
 2005.
+There is no release currently in progress, although development on the
+trunk for a future 10.1 release has begun.
 
 Any release must be approved by the Incubator PMC and must clearly be
 marked as an incubator release, according to the Apache Incubator
@@ -317,84 +191,6 @@
 
 http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0A
 
-Open showstoppers:
-
-  None.
-
-Resolved showstoppers:
-
-  DERBY-24 Client should not be able to raise an event on a
-  PooledConnection it no longer owns.
-
-  DERBY-32 Logic to prevent mutiple jvms booting the same database in
-  parallel to avoid accidental corruptions on Unix environment is not
-  working.
-
-Resolved non-showstoppers:
-
-  DERBY-6 Trigger of the form: create trigger ... values myFunction();
-  has no effect.
-
-  DERBY-14 Triggers do not evaluate functions in VALUES trigger
-  actions.
-
-  DERBY-21 ResultsetMetaData.getColumnClassName() for CLOB and BLOB
-  datatypes is incorrect.
-
-  DERBY-30 Connection.close() method inconsistently throws exception
-  on closed connection
-
-  DERBY-35 DRDA Chaining in Network Server is incorrect
-
-  DERBY-38 Make LOCKS as non-reserved keyword in Derby since it is not
-  a reserved keyword in the SQL standards
-
-  DERBY-40 Cannot set default value for BIGINT
-
-  DERBY-42 When using encryption, do not store the length information
-  about the external key in service.properties
-
-  DERBY-44 Support for like ? Escape ?
-
-  DERBY-50 getMaxColumnNameLength() database metadata function returns
-  incorrect value.
-  
-  DERBY-54 'retain' was not a keyword, now it is, possible schema
-  impact
-  
-  DERBY-59 dblook currently has driver classes hard coded
-
-  DERBY-67 Network Server on a 64 bit JVM fails with: Execution failed
-  because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT
-  arg = 2116; Error Code Value = 14
-
-  DERBY-72 IBM (c) message in properties files
-  
- 
-Items deferred to next release:
+The changes made in the 10.0.2.1 release can be found in the CHANGES file:
 
-  [PATCH] retrieveMessages... true by default in ij
-  The original submitter of this patch (myrnap) requested that it not
-  be applied to the current release due to an issue when setting the
-  property on the command-line and passing the same property with the
-  connection URL.
-
-Other applied patches:
-
-  [PATCH] Optimization of
-          org.apache.derby.impl.services.uuid.BasicUUID.toByteArray()
-  [PATCH] Set Derby's build number to be the subversion revision number
-  [PATCH] derby.war file build
-  [PATCH] derby.log file error message
-  [PATCH] Network servlet display only message key
-  [PATCH] added 3 more parser generated files to the clobber target in
-          main build.xml
-  [PATCH] Various fixes to javadoc generation
-  [PATCH] Trigger Bug Fix
-  [PATCH] Fix to prevent empty log file switches that could cause
-          recovery failures
-  [PATCH] ExternalSortFactory Bug Fix
-  [PATCH] Modify dblook messages to enable localization ...
-  [PATCH] minor bugs in dblook 
-  [PATCH] Extension Packaging
-  [PATCH] DB Shutdown fix for Network Server
+http://svn.apache.org/repos/asf/incubator/derby/code/branches/10.0/CHANGES

Mime
View raw message