>> 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
>> Personally, I am now in favor of the odd-even scheme recommended by Daniel. >> >> Q: What do other people think? > >I prefer this option too. Me too, next release will be 10.2 then (no 10.1) Nico ------------------------------------------------------- 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
