Doug Morris <[EMAIL PROTECTED]> writes:
> >> The only modification to VERSION that I think could make sense
> >> (though I still think it is unnecessary) would be to tag it as
> >> '1.0.2-dev' or something similar, with the full '1.0.3' being added
> >> at release, and then immediately modified to '1.0.3-dev' for the
> >> time during development. This prevents the number from skipping up
> >> by twos, and would provide the division you seem to want between
> >> in-development versions and releases.
> >
> >Again, as I said in another email, I dislike 1.0.3-dev (or 1.0.3-beta or
> >1.0.3-pre) because it implies that the next released version will be 1.0.3,
> >and this may not be the case. It may be 1.1[.0].
>
> If you reread, I think I'm saying what you say below -- I think if we
> went to a '-dev' revision it should be '1.0.2-dev' and not
> '1.0.3-dev'. You're right, we shouldn't imply that we know what the
> next revision should be.
Ah. I misunderstood because "1.0.2-dev" implies to me a developer version
of 1.0.2 -- i.e. something preceeding the release of 1.0.2. I would much
prefer "1.0.2+dev". That implies 1.0.2 plus some development. Much less
easy to accidentally drop the suffix than a single '+', too.
> I'm in MET,
Middle Eastern Time?
> but there are a lot of people in the US. I can easily
> imagine a case where I update the repository, and you follow on a few
> hours later with a new commit, but a timestamp that's earlier than
> mine becuase you're in a later timezone.
>
> The repository is in US/Eastern, but I dislike using an arbitrary zone
> as the timestamp. It's easier to convert to GMT than to EDT/EST. (is
> that GMT-4 or -3? before or after the time change?)
You could just use the integer value of the current time_t. If people
wanted to convert that to a time in their local time zone, they'd be welcome
to. A little long and messy, perhaps, but it doubles nicely as a serial
number. The current time as I write this is 941578830.
> It might be simpler to update to 1.0.2.{1,2,3,4} etc. That makes it
> less simple to check out based on date, but you should be able to
> check the archive, grab the datestamp, and check out based on that. At
> least until it's possible to automate the date/time stamping.
That would make comparison of different versions a lot easier than the
integer timestamp method.
> On rereading, all of the alternatives above seem fairly messy except
> for the 1.0.2+/1.0.2-dev scheme. I'd suggest we just go with that
> and if someone complains about a dev version, the resolution is to
> grab a newer one or to use a stable release. I prefer the -dev suffix
> more than + since it's a bit more obvious that this is "in
> development" rather than "a bit better".
Well, like I said earlier, how 'bout combining the two as "+dev"? I'll go
ahead and change it to that for now. If anyone has a better alternative,
post it to the list.
-----------------------------------------------------------------------
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.
