[Kst] kdeextragear-2/kst/devel-docs

George Staikos staikos at kde.org
Sat Oct 16 22:17:26 CEST 2004


CVS commit by staikos: 

What a 1.0 means


  M +49 -7     RELEASE_PLAN   1.52


--- kdeextragear-2/kst/devel-docs/RELEASE_PLAN  #1.51:1.52
@@ -1,12 +1,14 @@
-Certain areas should not be hacked without first bouncing it off of the
+-----------------------------------------------------------------------------
+NOTE:
+Certain areas of Kst should not be hacked without first bouncing it off of the
 section's maintainer (discussion on the list is the best):  For section
 maintainers:
-  -Updates and class structures, lists, globals, threads: George
-  -Filters, Fits, Elog, Events: Andrew
-  -Dialogs: Barth
-  -New Features: The List
+  - Updates and class structures, lists, globals, threads: George
+  - Filters, Fits, Elog, Events: Andrew
+  - Dialogs: Barth
+  - New Features: You must discuss new feature introduction and design on the
+                  list or at least bugzilla before proceeding.
 If someone bounces something, !respond!.  If no one responds, mods are fair game.
-
-Next release: 1.00
+-----------------------------------------------------------------------------
 
 Refer to bug tracker for all outstanding bugs and features...
@@ -16,8 +18,14 @@
 NOR - should be fixed/implemented (may require discussion)
 
+
+Next release: 0.99b
+
+
+
 1.0 Release Requirements
 ------------------------
 - Verify which headers and libraries are installed, and only install the ones
   that we really have to
+- Strip down libkst as much as possible
 - Commit to binary compatibility on plugins and libkst
         - make sure virtuals are -only- where we need them
@@ -30,2 +38,36 @@
 
 
+1.0 Release Plan
+----------------
+1) Feature list / freeze to be determined
+
+2) Each and every .h file installed must be auditted
+        - check header file usage and forward declaration usage
+        - check friends
+        - check member variables
+        - check virtuals
+        - make sure there are d-ptrs, virtual_hooks
+        - make sure they're self contained and compilable
+        - check for guards
+
+3) Plugin spec must be frozen, and deprecated plugin formats removed
+
+4) Data source spec must be frozen, though new non-virtual members or statics
+   may be added later
+
+5) libkst must be auditted to remove all unnecessary code
+
+6) DCOP interface must be fully auditted.
+        - Each method must make sense
+        - spelling, argument types, argument formatting, etc must be correct
+          and consistent
+        - Remember that methods can be added, but not removed
+        - Should make sense for the future as well, so they aren't deprecated
+          as meaningless
+
+7) Extension interface must be reviewed to ensure that it provides enough or
+   can do so in the future
+
+8) Review the kst file format to make sure we don't have to break it again.
+        - Can we rebreak it before 1.0 if there are areas that look problematic?
+





More information about the Kst mailing list