directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tencé, Vincent" <vte...@optimuminformatique.com>
Subject RE: [release][ldap][asn1][apseda] Tagged to represent internal re leases
Date Mon, 17 Jan 2005 13:24:04 GMT
+1

> -----Original Message-----
> From: Enrique Rodriguez [mailto:erodriguez@apache.org]
> Sent: January 14, 2005 7:14 PM
> To: Apache Directory Developers List
> Subject: Re: [release][ldap][asn1][apseda] Tagged to 
> represent internal
> releases
> 
> 
> +1
> 
> Trustin Lee wrote:
> > +1
> > 
> > 
> > On Fri, 14 Jan 2005 18:04:25 -0500, Alex Karasulu 
> <aok123@bellsouth.net> wrote:
> > 
> >>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
> >>
> >>
> > 
> > 
> > 
> 

Mime
View raw message