I guess the wider question is, do we need to go to 1.0 after our milestone releases... or can we skip to 3.0 / 4.0 or whatever?
-- Rob On 14/01/2008, Rupert Smith <[EMAIL PROTECTED]> wrote: > 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 >
