So my preference would actually be to name our first post-graduation release N.0.0 where N is one greater than the number of our previous milestone release (e.g. if we graduate after M3, then the first post graduation release would be 4.0).
Perhaps we should take this conversation into to the wider group, as perhaps they do not read mails in the .net ghetto? :-) -- Rob On 14/01/2008, Martin Ritchie <[EMAIL PROTECTED]> wrote: > 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 >
