directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Rodriguez <>
Subject Re: [release][ldap][asn1][apseda] Tagged to represent internal releases
Date Sat, 15 Jan 2005 00:14:10 GMT

Trustin Lee wrote:
> +1
> On Fri, 14 Jan 2005 18:04:25 -0500, Alex Karasulu <> wrote:
>>Hi all,
>>NOTE: for internal releases we're only tagging so no distributions are
>>published to the incubator repo area under
>>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:
>>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:
>>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?

View raw message