In the past, I used the Perforce changelist number as the Build field. That way, I never ran into installer or binding problems because it was clear that each change automatically resulted in the build number increasing.
The build number can never decrease for a given major/minor pair, and no two releases can have the same major/minor/build triplet. If I release a beta build corresponding to each beta build of the Java version, then the following could happen: Java 3.2.0 C# 3.2.0 Java 3.2.1 C# 3.2.1 Java 3.3.0 beta 1 C# 3.3.0 Java 3.3.0 beta 2 C# 3.3.1 Java 3.2.2 (bug fix release) C# 3.2.2 Java 3.3.0 Final C# 3.3.2 <-- This is the "strange" one, because we have an "official release" with a small difference in version numbers. However, it's definitely the most reliable way to publish releases, so my vote is it's worth it. The installers are finicky. Things are a big pain if two incompatible builds ever share the same major/minor/build triplet. Seriously. Sam -----Original Message----- From: Johannes Luber [mailto:[email protected]] Sent: Sunday, October 25, 2009 12:49 PM To: Sam Harwell; [email protected] Subject: Re: [antlr-dev] Assembly versioning in the C# Port and CSharp3 target > 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: What are the unmentioned reasons exactly? > > 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. Why not doing the differentiation of previews/betas without matching Java version via simply an increased build number? > > 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. Isn't that bad (in general as well as for my proposal)? Can't you enforce to look for exact matches? Johannes > > > > Sam > -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 _______________________________________________ antlr-dev mailing list [email protected] http://www.antlr.org/mailman/listinfo/antlr-dev
