Sounds like 2.1.x.y is acceptable to most, so will use that instead of 0.2.1.x. Will help avoid any confusion with 0.2 artefacts.
On 14/01/2008, Carl Trieloff <[EMAIL PROTECTED]> wrote: > > Martin Ritchie 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. > > > > > > > ack, don't have to have incubation and 1.0 be the same date. We can make > M2 our 2.x and M3 > our 3.x release and so forth. > > Carl. > > > >
