Date: 2004-12-01T19:16:07 Editor: AlexKarasulu <[EMAIL PROTECTED]> 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.
