Egon, I want to start a dialog about planning the upcoming release schedule for Jmol.
The g3d code is in pretty good shape. And over the next few weeks I want to start wrapping it up for pre-release testing. In addition, I want to reraise the issue of the release numbering convention. I want to slow down the increment counter for major version releases ... to comply more with software industry conventions. I propose the following: - release version 8 soon - reserve version number 9 for a future release of changes/bug fixes to the b6 branch - the g3d code will be used in releases starting with version 10 Beginning with release 10, we will follow the following convention: - then, follow a scheme of MajorVersion.MinorVersion.bugfix - MajorVersion will be reserved for significant rewrites - Every feature addition will increase the MinorVersion - bug fixes will not release the MinorVersion version - *every* release to sourceforge changes a number - every release has three number i.e. 10.0.0 I am still thinking about the pre-release versioning. I don't really like using letters. Nevertheless, this is my current thinking: - Prerelease versions use a letter as the MinorVersion - a => alpha test - internal - b => beta test - external - c => candidate release - alpha test would be 10.a.0, 10.a.1, etc. - beta test would be 10.b.0, 10.b.1, etc. - candidate releases would be 10.c.0, 10.c.1, etc. As I said, I hope to start some prerelease testing of the g3d code within the next few weeks. So we will have to give it a name. Let me know what you think. Miguel ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
