The assembly files for the .Net are incorrect in that they list the version of it as 0.5.x. I think it is very useful to have version numbers embedded into binary builds (also timestamps and subversion revisions numbers are nice too), as it really helps to solve 'lost' library problems. The conventional version numbering scheme for .Net is:
major.minor.days.seconds or major.minor.num_days_since_jan_1st_2000.seconds_since_midnight_divided_by_2 The reason the seconds since midnight is divided by 2, is so that this number fits into a 16-bit integer. Yes, this version format allows a maximum of four 16-bit ints. What I want to know is, would it be ok to correct the version stamp for the next release (M2.1) to be: 2.1.x.y or should I use: 0.2.1.x? That is, will version numbering go from the M2.x, M3.x range eventually onto a 1.x range after graduation, meaning that I should not use the 2.1.xversion now, as one day there may really be a 2.1.x version of Qpid? In which case 0.2.1.x is the best I can do with this version format to accurately represent where we are. Going for 0.2.1.x unless anybody objects... I will stick svn revision number in another property too. Rupert
