Hi everyone,
After messing with revision number schemes in other projects, I've come up with one I believe is preferable for a number of reasons. Here is the scheme: Revision numbers are of the form Major.Minor.Build.Revision. Major and minor will reflect the corresponding Java version's major/minor numbers. For example, the current release would start with 3.2. While in development, the code slated to become 3.3 (say 3.3 beta 1) would start with 3.3. The build number will be incremented once each time a public build is posted. When the major and/or minor number changes, this number resets to zero. If I post two public builds with the same major/minor/build numbers, it will cause extremely irritating problems with assembly resolution and install processes for users, which leaves two choices: 1. Keep this number in sync with the Java version. To do this, I would post 1 public build for each publicly posted ANTLR release. No previews/betas would be posted between times when the Java build number increments. 2. Let this number get out of sync with the Java version. This means I can post previews/betas between the regular releases. This is the scheme I lean towards. At the time I build a public build, the revision number will always reflect the source control changelist number containing the code I'm building. The number increases over time and is never reset. The Windows Installer does not look at the revision number when checking to see if the current version of an application is already installed. In other words, if you have 3.2.2.1000 installed and you try to install 3.2.2.1001 installed, it will inform you that you already have the same or newer version installed and exit. Sam
_______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev
