Mailing-List: contact directory-cvs-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: directory-dev@incubator.apache.org
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: directory-cvs@incubator.apache.org
To: directory-cvs@incubator.apache.org
Subject: 
 =?iso-8859-1?q?=5BApache_Directory_Project_Wiki=5D_Updated=3A__ReleasesHo?=
 =?iso-8859-1?q?wto?=
Date: Thu, 02 Dec 2004 03:16:07 -0000
Message-ID: <20041202031607.99987.73869@minotaur.apache.org>

   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 @@
 =

 =3D=3D First time releasing =3D=3D
 =

-* 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.
+=3D=3D=3D What can we release? =3D=3D=3D
 =

-  ** 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 n=
eeds an overhaul with serveral jars
+  ** naming - looks great with a single jar
+  ** kerberos - ok for first release but definately alpha grade with one j=
ar
   ** 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 releas=
e together unless one has dependencies on the release of another.  Also som=
etimes it might make sense to release all together if 5 out of six are alre=
ady 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.
+
+=3D=3D=3D What release numbers do we start with? =3D=3D=3D
+
+* I think we want the release number to be a line in the sand as well as a=
n indicator of the level of quality the software is in.  So to figure out t=
he 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 numbe=
rs are experimental branches of development and even minor numbers are stab=
le branches.  We can increment the 3rd minor number for bug fix releases of=
 stable branches or for functional enhancements in unstable development bra=
nches.  =

+
+* However we really don't want to start at 1.0 because this implies a full=
y 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 basicall=
y then have to do an exercise for all projects by drawing out their roadmap=
s until a 1.0 is reached.
+
+=3D=3D=3D Eve Roadmap for 1.0 =3D=3D=3D
+
+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 administ=
ration
+
+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
+
+
+=3D=3D=3D Eve Roadmap for 1.2 =3D=3D=3D=3D
+
+
+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 ~=3D 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 compl=
exity at no benefit IMO)
 =

 =

+* So for Eve we have boat loads of work to do before a 1.0 is available an=
d this is pretty strict BTW.