[reSIProcate] Calling all devels: Getting release notes ready, other release work.

Alan Hawrylyshen alan at polyphase.ca
Mon Aug 21 12:36:11 CDT 2006


On 2006.08.21, at 08:59 , Byron Campen wrote:

> -Naming-scheme for this release (and following releases)

I have no particular religion around this, but it needs to be a  
functional name. That means the top-level directory needs to  
represent the project and version number. We've used BOTH resip and  
resiprocate in the past. I think we should use resiprocate, since  
that is the name of the project.

Therefore I loosely propose (as both administrator and someone with  
software management experience) we use names of the form:

resiprocate-MAJOR.MINOR[.PATCH]-ANNOT

Where MAJOR and MINOR would likely be 1 and 0 respectively and for  
now there is no patch level.
-ANNOT would be things like 'alpha', 'beta', etc. OR, 'RC1' ...  
'RC3' ... 'RC'n until we are happy to promote to an annotation free  
name.

Things like the following would be a reasonable progression:
resiprocate-1.0-rc-1
resiprocate-1.0-rc-2
resiprocate-1.0-rc-3
resiprocate-1.0

The critical elements here would be that resiprocate-1.0 would be  
IDENTICAL to the last -rc- release done and differs only in tagging.

No need to embed the subversion version number because we are  
treating these as TAGS not branches.

THAT SAID, there is an alternate approach: we create a  
resiprocate-1.0-beta BRANCH and tweak it until we agree that a  
particular svn revision represents a 'good to go' 1.0 release. Then  
we 'tag' and release. Any changes on the -beta branch would need  
merging back to trunk.

Anyone have a preference? The advantage of the beta branch is that it  
is slightly less confusing IFF we can remember that snapshots need to  
include the svnrevision number in the tarball name UNTIL we go 'gold'.

The -rc-1 through -rc-n approach has the advantage of being very  
explicit.

Comments?

Alan


  



More information about the resiprocate-devel mailing list