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? 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.
Bill
