On 14/01/2008, Robert Godfrey <[EMAIL PROTECTED]> wrote: > 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 > >
As much as I'd love to have a graduated 1.0 release marketing speaks volumes and IIRC Active MQ never had M releases they were up to 4.x before graduation and kept going in that approach. The only post graduation excitement is to remove -incubating from the artifacts. -- Martin Ritchie
