directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Directory Wiki] Update of "ReleasesHowto" by CKoppelt
Date Tue, 13 Feb 2007 21:22:15 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Directory Wiki" for change notification.

The following page has been changed by CKoppelt:

The comment on the change is:

- = Describes the Directory Project's Release Process =
+ deleted
- "This wiki page is here because Alex started thinking about how in the world we are to handle
releases. Furthermore how will releasing out of the incubator effect this process as well
as the fact that this is the first time we are releasing anything."
- == First time releasing ==
- === What can we release? ===
-  * 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 - in fact it comes as several
jars, but I can look into producing a single one (Vincent)
-    * 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
- === 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.
- === Roadmap for Eve ===
- ==== Eve Roadmap for 1.0 ====
-  1. Add support for controls and implement a few useful/common ones
-     a. Persistant Search Control
-     a. Sort Control
-     a. Named References/ManageDsaIT
-  1. Complete all JNDI operations and Schema support in Eve JNDI provider
-  1. Complete support for most schema checking constructs
-     a. objectClass
-     a. attribute syntaxes
-     a. matching rules
-     a. dit structure rules
-     a. dit content rules
-     a. name forms
-  1. Enable minimal subschemaSubentries and Authoritative Areas for administration
-  1. Flexible ACI/ACL based authorization system
-  1. Better transaction management and ACIDity instead of using buffer cache
-  1. Replication piggybacking on queueing technologies
-  1. Triggers and Stored Procedures
-  1. Better error handling and easily understood messages
-  1. Awesome documentation and tools
-  1. Correct Abandon operation handling
-  * So for Eve we have boat loads of work to do before a 1.0 is available and this is pretty
strict BTW.  We're asking a lot out of 1.0 but this can be changed.  For now when trying to
decide release numbers we can use this to gauge what number to start on.  Perhaps we should
also look at what a 1.2 might have in store below.
- ==== Eve Roadmap for 1.2 ====
-  1. Language Tags
-  1. In memory backend alternatives
-  1. Support collective attributes
-  1. Support dynamic attributes 
-  1. SASL/GSSAPI/Kerberos support
-  1. DNS-based service location
-  1. Password Modify 
-  1. 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)
- === Ok so what's the first release revision for Eve already? ===
-  * This exercise has been good.  We have done a lot in the past year under the incubator
but have a lot more to go.  I think we can start off with a release at 0.8.0.  We can have
small bug fix releases on this branch enumberating like so, 0.8.1 ... 0.8.nnn to whatever.
 This is a stable branch (although not production grade) meaning we will not do active development
on it but try to stabilize the code with the set of features that are in existance.
-  * The choice to go 0.8.0 makes sense since LDAPd's last version was 0.7.11 and that was
way lame in comparison to Eve.  Eve's got a leg up on LDAPd in several ways we can't enumerate
here not to mention everything is IP free and implemented from the ground up like ASN.1 BER
libraries et cetera.
-  * After releasing 0.8.0 we start getting feedback and collecting the bugs while active
developement continues on the trunk.  However in the trunk we work on revision 0.9.0 and increment
for all the new features added on the roadmap to 1.0.0.   
-  * Basically this is good to do. Why? Cuz Eve at this point has most of her foundations.
 Everything else is a matter of building up on this base.  So this core will not change that
agressively hence keeping a stable branch for working out bugs and issues is great.  This
will also feed back into the development branch when fixes in it are merged back.
- === What is needed for Eve 0.8.0 to be released ===
-  * First off we need documentation that is up to date and the site must also be up to date
to reflect the status of the software.
-  * We need to have what's there working properly.  So then I guess we need to define what
-     * the JNDI provider is operational although schema access does not exist yet
-     * the protocol supports core operations minus extended ops and abandon
-     * size and time limits are not honored
-     * aliases work
-     * schema is not published
-     * subschema subentires do not exist
-     * simple bind is supported only
-     * no controls are supported yet
-     * operational attributes in 2252 are supported
-     * no schema checking enabled
-     * interceptor framework is in place and it works
-     * multiple partions work
-     * schema subsystem for bootstrapping works
-  * We need to let users know that if you want to store, retrieve and search for entires
then Eve will do that at this point.  Anything more than the trivial simple stuff may not
be there like controls and such.  It's a bit limiting.  However building on this will be very
rapid thanks to the interceptors.

View raw message