directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From directory-...@incubator.apache.org
Subject [Apache Directory Project Wiki] Updated: ReleasesHowto
Date Thu, 02 Dec 2004 03:16:07 GMT
   Date: 2004-12-01T19:16:07
   Editor: AlexKarasulu <akarasulu@apache.org>
   Wiki: Apache Directory Project Wiki
   Page: ReleasesHowto
   URL: http://wiki.apache.org/directory/ReleasesHowto

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -4,15 +4,84 @@
 
 == First time releasing ==
 
-* Ok we want to release some code but what will that code be exactly.  We have a few projects
each with a deliverable or more.  Let's start by trying to guage the health and usability
of each project.  If I'm wrong anywhere let me know by making corrections.
+=== What can we release? ===
 
-  ** janus - looks good for a beta
-  ** eve - ok for first release but is alpha quality
-  ** ldap - oh yeah has been ready for a while and is kind beta grade
-  ** snickers - ok for first time but definately alpha crud that needs an overhaul
-  ** naming - looks great 
-  ** kerberos - ok for first release but definately alpha grade
+* Ok we want to release some code but what will that code be exactly.  We have a few projects
each with a deliverable or more.  Let's start by trying to guage the health and usability
of each project.  If I'm wrong anywhere let me know by making corrections to this page.
+
+  ** janus - looks good for a beta and seems like a single jar
+  ** eve - ok for first release but is alpha quality and has a single jar
+  ** ldap - oh yeah has been ready for a while and is kind beta grade with a single jar
+  ** snickers - ok for first time release but definately alpha crud that needs an overhaul
with serveral jars
+  ** naming - looks great with a single jar
+  ** kerberos - ok for first release but definately alpha grade with one jar
   ** rms - heck no (looks like a lost cause right now)
 
+* We got a bunch of projects of varying maturity.  It makes sense to make them be able to
release on their own.  There is no need to have them release together unless one has dependencies
on the release of another.  Also sometimes it might make sense to release all together if
5 out of six are already being released.  We want to release anything that works and anything
we want exposed to users.  I think all projects minux rms are good candidates as mentioned
above.
+
+=== What release numbers do we start with? ===
+
+* I think we want the release number to be a line in the sand as well as an indicator of
the level of quality the software is in.  So to figure out the release numbers we start with
we need to figure out a versioning scheme.  
+
+* I kind of like the idea of major and minor numbers where odd minor numbers are experimental
branches of development and even minor numbers are stable branches.  We can increment the
3rd minor number for bug fix releases of stable branches or for functional enhancements in
unstable development branches.  
+
+* However we really don't want to start at 1.0 because this implies a fully functional, generally
available and stable first release.  I don't think we're there yet :-).  So a 0.something
is best but do we use an even minor number or an odd one?  And regardless which one do we
start off on because surely not all projects are at 0.1.0  This does not seem right.
+
+* So hears another hint each project within directory will need to decide what it's release
numbers will be.  Each is different.  
+
+* To really figure out a starting release number below 1.0 I guess we have to figure out
how far we have until a 1.0 in terms of features.  Based on that we can gauge the starting
version number for the release.  We basically then have to do an exercise for all projects
by drawing out their roadmaps until a 1.0 is reached.
+
+=== Eve Roadmap for 1.0 ===
+
+1. Add support for controls and implement a few useful/common ones
+   a. Persistant Search Control
+   b. Sort Control
+   c. Named References/ManageDsaIT
+
+2. Complete all JNDI operations and Schema support in Eve JNDI provider
+
+3. Complete support for most schema checking constructs
+   a. objectClass
+   b. attribute syntaxes
+   c. matching rules
+   d. dit structure rules
+   e. dit content rules
+   f. name forms
+
+4. Enable minimal subschemaSubentries and Authoritative Areas for administration
+
+5. Flexible ACI/ACL based authorization system
+
+6. Better transaction management and ACIDity instead of using buffer cache
+
+7. Replication piggybacking on queueing technologies
+
+8. Triggers and Stored Procedures
+
+9. Better error handling and easily understood messages
+
+10. Awesome documentation and tools
+
+11. Correct Abandon operation handlingg
+
+
+=== Eve Roadmap for 1.2 ====
+
+
+1. Language Tags
+
+2. In memory backend alternatives
+
+3. Support collective attributes
+
+4. Support dynamic attributes 
+
+5. SASL/GSSAPI/Kerberos support
+
+6. DNS-based service location
+
+7. Password Modify 
+
+8. Enable ~= using soundex algorithms (might pass on this - no one uses it or is stupid enough
to depend on it so its mostly a toy which adds complexity at no benefit IMO)
 
 
+* So for Eve we have boat loads of work to do before a 1.0 is available and this is pretty
strict BTW.

Mime
View raw message