On Jan 3, 1:13 pm, Sebastien Lelong <[email protected]> wrote: > > > Other projects have the concept of 'release candidates'. We could > jallib also has this concept, even if not named the same. As Rob explained, >
Is there anything written down about JALLIB's release process and concepts? This is a sincere question -- perhaps I've overlooked it. Also, I guess I've been using the term 'branch' too loosely. I know that in Subversion, branches and tags are the same 'under the hood' I am using this document as my guide to Subversion terminology. Is it the correct document? http://svnbook.red-bean.com/en/1.1/ch04.html Another question - since I am relatively new to JALLIB, do we really do 'branches', or, do we mostly do 'tags'? A branch, implies that you would be maintaining (bug-fixes, etc) multiple versions of JALLIB. Similar to Linux kernel -- there is a 2.4.x series and a 2.6.x series, and both are still actively being maintained. A tag, seems to me, is more like what we do here-- once in a while, we issue a 'release', and that is it, no bug fixes, until the next 'release'. And no support for older 'releases' -- instead, everyone must upgrade to the latest/current release. I will try to use the term 'tag' in the future. So, my suggestion for release process is: 1) tag a candidate release in Subversion 2) test it for nnn days 3) After nnn days, if less than yyy non-critical bugs reported, then 4) release it. If 3) above fails, then we must start over at step 1. What have I forgotten? Constructive comments and suggestions are welcome! William -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
