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:20:13 GMT
   Date: 2004-12-01T19:20:13
   Editor: AlexKarasulu <akarasulu@apache.org>
   Wiki: Apache Directory Project Wiki
   Page: ReleasesHowto
   URL: http://wiki.apache.org/directory/ReleasesHowto

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -20,15 +20,15 @@
 
 === 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 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.  
+ * 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.
+ * 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.  
+ * 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.
+ * 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 ===
 
@@ -64,6 +64,9 @@
 11. Correct Abandon operation handlingg
 
 
+
+ * 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 ====
 
 
@@ -83,5 +86,3 @@
 
 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