Well, I just checked in the 0.2.1.x solution, but can easily change it to 2.1.x.y. There may be older pre-apache versions of the .Net around which have a 0.2 stamp in them already, but they can be told apart from the current efforts, because the namespace was change from 'Qpid.' to ' Apache.Qpid'. Also, I have put the output of 'svnversion' into the description field of the assembly, which shows up as a comment when you look at the properties of the .dlls.
Perhaps best not to take this to the wider group, as I don't want to start a highly pointless and extremely long discussion about version numbers all over again ;) I now its everybody's favourite topic but... Rupert On 14/01/2008, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > 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 > > >
