I am going to try to restart the 'release numbering' discussion. Our numbering scheme needs to support both public stable releases and internal development releases.
>From a timing perspective, I believe that we should plan on doing several public releases per year which introduce new features. (We can discuss this in more detail later.) However, more frequent public releases does not eliminate the need to fix bugs in public releases. When we do a public release, we will make a branch in the svn repository. We should be prepared to do a small number of bug-fix fix releases against that branch. Our numbering scheme needs to uniquely identify those minor bug-fix releases. As someone pointed out, a Jmol user should expect to be able to take a minor bug-fix release and plug it into an existing web-site or application with full confidence that no script commands have changed and that nothing will break. After doing a public release, the development will continue along the main trunk. Those revisions are targeted at developers and more adventurous users. The numbering scheme needs to branch and support changes in revisions along each branch independently. Daniel pointed out that many open source projects have adopted the odd-even scheme ... internal development releases are odd and public releases are even. Under this scheme. 10.2.0 -> public 'feature' release - 10.2 branch is created 10.3.0 -> development trunk immediately becomes 10.3 10.3.1 -> development prerelease 10.3.2 -> another development prerelease 10.3.xx In parallel with this: 10.2.1 -> first public bug fix release, fixed in 10.2 branch 10.2.2 -> second public bug fix release, fixed in 10.2 branch 10.4.0 -> following public release - branch is created 10.5.0 -> development trunk immediately becomes 10.5 When I sent out my first message I proposed: 10.1 (official public release) 10.11 (first public bug-fix release) 10.12 (second public bug-fix release) 10.2 (following public release) Daniel said that 10.11 > 10.2 ... revealing my 'decimal point centric' view of the world. Personally, I am now in favor of the odd-even scheme recommended by Daniel. Q: What do other people think? Miguel ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
