"Dan Harkless" wrote:
>> 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.
>If you're violently against the even/odd version number dichotomy, I could
>live with changing the version number to "1.0.2+". In fact, that
I not *violently* opposed to it. I won't come after you with a knife
or anything ;-)
>However, there's more opportunity for confusion with the plus sign being a
>significant character. Someone not familiar with the convention (or even
>someone who is) might inadverantly drop it and just say "1.0.2". On the
>other hand, there's little opportunity for confusion between "1.0.2" and
>"1.0.3".
I think this argues more for a meaningful convention such as -dev,
rather than simply 1.0.2+. Datestamping, as Dan Winship mentions
later, would be useful, and may be something we can add using the
commitinfo, or cvswrappers hooks in cvs. They're not intended for
that, so it'd be a bit of a hack, but I can look into it. It would
have to be date+time stamping, though, to get sufficient granularity
to be useful, since multiple commits in a day are non unusual.
An intermediate alternative to having CVS automate this would be to,
in fact, update the VERSION file every time you commit. In that
case, a datestamp might not be good. If we have to manually update
including the date, we need to always convert to GMT.
I'm in MET, 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?)
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.
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".
On an unrelated note, I'm flying to the US tomorrow for three weeks,
which means my responses on this list will be slower than usual. I'll
be at the LISA conference in seattle beginning on the 6th. If anyone
else is going to be there, let me know. We can kvetch about version
numbering in person. :)
-Doug
