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.
