Scott Blachowicz <[EMAIL PROTECTED]> writes:
> > I've never been a fan of the internal vs. external release number idea.
> > If we have 1.0.2 being released then 1.0.4, people may wonder whatever
> > happened if 1.0.3 and so on...
>
> Same here...I may be old-fashioned, but I think the version number should be
> generally increasing over time,
It will.
> so bouncing between even & odd release numbers over time seems weird.
There's no bouncing between them. People with FTP access get the
even-numbered releases. People with CVS access can get the odd-numbered
developer versions in between as well.
> And, bumping the version number to 1.0.3 before 1.0.3 is released seems
> weird, but the number should always change as a new release is put out.
> Maybe that means I'd prefer having X.Y.Z where X is major version, Y is
> minor version and Z is development-in-progress version. So, public
> releases would've been 1.0.0, 1.1.0, 1.2.0. And instead of bumping from
> 1.0.2 to 1.0.3 on this public release, I would've released 1.2.0,
Not 1.1.0?
> then bumped to 1.2.1 for the next chunk of development.
That's fine, but there'd really never be a reason to increment Z past 1, so
why give it the status of a full digit? You can communicate the same
information more concisely (and without loss of version number resolution)
with an even/odd convention (or a "beta" string).
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
[EMAIL PROTECTED] | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
