Hi all,

NOTE: for internal releases we're only tagging so no distributions are 
published to the incubator repo area under cvs.apache.org. 

I kind of messed up a couple times but I finally froze (meaning removed 
SNAPSHOTs) on ldap, asn1 and apseda projects.  Then I tagged the trunk 
with the non-SNAPSHOT versions: this was a trunk to tags svn copy 
operation.  Then I bumped the revision in trunks to the next level as 
SNAPSHOTS.  So we had:

ldap on 0.8-SNAPSHOT
asn1 on 0.2-SNAPSHOT
apseda on 0.2-SNAPSHOT

Now we have the following tags with revisions:

ldap/tags/internal-release-0.8
asn1/tags/internal-release-0.2
apseda/tags/internal-release-0.8

The trunks now are at the following revisions:

ldap on 0.9-SNAPSHOT
asn1 on 0.3-SNAPSHOT
apseda on 0.3-SNAPSHOT

We can now start to work on the next best thing within these trunks 
which represent branches where we can have development (experimental) 
releases.  Incidentally we can tag and release any number of dev release 
off of these dev branches.  For example 3 release iterations of the ldap 
dev branch may produce the following versions:

0.9
0.9.1
0.9.2
...

We can continue to give back the community new features until we decide 
to have a feature freeze.  Then we can bump up to 0.10 to stablize the 
code and have a stable release.  The next dev branch would then be 0.11 
and so on.  So the general pattern here is pretty obvious.  I should 
look at the release plugin to make this model work more smoothly for us 
and perhaps others.

When we feel confident with the feature set and the stability of the 
product we can release a few 1.0 release candidates.  Btw there is no 
reason why every project must move in unison. 

Comments? Thoughts?

Alex