stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: x.y.z numbering and releases
Date Mon, 23 Jan 2006 18:49:27 GMT
William A. Rowe, Jr. wrote:
> Martin Sebor wrote:
> 
>> William A. Rowe, Jr. wrote:
>>  >
>>  >> [...] I suspect that may not fully
>>  >> address your concerns (i.e., the fact that there is a 1.2.3 branch
>>  >> before an official release has taken place).
>>  >
>>  >
>>  > I do believe it does, granted the 1.2.3-rc3 branch would be internally
>>  > labeled (version id) 1.2.3, but the branch it sits on and the tarballs
>>  > it's packaged in both clearly designate 1.2.3-rc3...
>>
>> I'm not dead set against the x.y.z-<suffix> convention but as I said
>> before, I'm not convinced that obfuscating the upcoming version in
>> the name of the branch is necessary. In addition I can imagine
>> situations where the specific "candidate" suffix would be inappropriate.
>> Consider the not so uncommon case where development happens in parallel
>> on two (or more) branches in addition to trunk/. For instance:
>>
> ... branches/1.2/     <== current development of 1.2
> 
>>   branches/1.2.3/   <== to be released
>>   branches/2.0/     <== future binary incompatible branch
> 
> 
> Did I understand this correctly?

Yes.

> If so, yes I can agree that -candidate
> might be overkill.  Let's consider, it's really no different if someone
> picks up 1.2.3 and sends us some report about it, than if they pick up the
> 1.2 branch and report an issue.
> 
> Since tags/ is where to look for a specific release, and most folks do know
> that branches/ are dynamic points in time, I guess my concern is unfounded.

Yes. I think it's a matter of clearly documenting the branching (and
versioning) policy and the release process rather than trying to come
up with a foolproof naming convention.

Martin

Mime
View raw message