The comment is partly right. The code linked is not used to build NUnit. Rather, it is munged by our build script. See
https://github.com/nunit/nunitv2/blob/master/scripts/nunit.common.targets#L40 I can see why the package maintainer didn't use that script, since the revision would have reflected the date on which he built it rather than our revision number. However, using 13283 would lead to a better user experience. In the long run, it seems clear that version numbers should NOT be based on the date of build in order to be suitable for distros that require building from source. The number could be based on release date, but would have to be hard-coded in our source. This would seem to rule out the use of major.minor.*.* as well. I'll work on that for the next release (3.0.2 or 3.2.0 as the case may be) Meanwhile, however, it would make sense (to me anyway) to change this in the package distribution. NUnit 2.6.3 is several releases old and we won't be doing any new releases. BTW, is there any guidance anywhere that tells the upstream developer how to make sure a CIL package is suitable for packaging? On Thu, 3 Dec 2015 12:47:45 +0000 Jo Shields <direct...@apebox.org> wrote: > On Wed, 02 Dec 2015 10:05:45 -0500 Chris Capon <ttab...@gmail.com> wrote: > > When the major/minor version numbers are the same, the Debian GAC > reference > > MUST match the one released by NUnit.org or you break software > compatibility > > across systems. > > We're not touching this. The version number is defined in the source > code, and does not include a revision. See > https://github.com/nunit/nunitv2/blob/master/src/CommonAssemblyInfo.cs > > This sounds more like an error upstream - for some reason, they're not > building from the same source code they're distributing. > > > >
