Re: [Serusers] lost in cvs tags - difference between 0.9.3 and rel_0_9_0

:-) I just got this explained from Jan. He will update the CVS repository policy document recently submitted to CVS with some more details on this area. But for the time being... For the sake of non-CVS users: rel_0_9_0 is a CVS branch. A branch can be named anything, for example rel_stable_to_be. When you want to split the code in two, i.e. continue adding features to one code set, while only doing bug fixing in another, you create a branch. After a branch, each branch will be maintained separately. This means that if you do a bug fix to the rel_stable_to_be branch, you need to add the same change to the same file in other branches too. rel_0_9_0 means loosely "the branch that will be the next stable release with version 0.9.something". A less confusing branch name would probably be rel_0_9_x. Within each branch, the Makefile.defs has some parameters defining the actual version where also the last digit is set. The rel_0_9_0 branch has now reached version 0.9.3 (which you can verify in the Makefile.defs file). The source package called 0.9.0 at http://ONsip.org/ is a package with the files from branch rel_0_9_0 at the date specified in the description field and in the README.ONSIP file. Bug fixes have been added after that (in fact, the current ONsip.org Getting Started source package is version 0.9.2), so one have to run the cvs_update script to get the latest changes. We also update the package once in a while where this update has been done. For the sake of completeness: The non-branched code tree, i.e. the one you get unless specify a branch name (called a tag), is referred to as CVS HEAD or trunk (talking tree metaphores...) The head/trunk can at times be impossible to compile, because developers add new functionality that may break things they didn't foresee (even though it compiled on their machine, other things may influence compilation). Also, added functionality may break other functionality, so even though SER compiles, you may end up with problems with your ser.cfg because the developer haven't tested exactly that scenario. These problems should be reported at http://bugs.sip-router.org !! Hope this helps :-) g-) Within each branch Klaus Darilion wrote: