This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Question about clisp version naming
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 12 Mar 2015 07:43:12 +0100
- Subject: Re: Question about clisp version naming
- Authentication-results: sourceware.org; auth=none
- References: <5500B536 dot 4050108 at cornell dot edu> <1426112433 dot 11504 dot 18 dot camel at cygwin dot com>
Yaakov Selkowitz writes:
>> My work was based on the tip of the upstream Mercurial repository, which
>> shows a version number of 2.49+ and is at revision 15623. So I was
>> thinking of using 2.49+hg15623 as the version number. Will upset be
>> happy with that? Or is there some other standard way of assigning
>> version numbers in cases like this?
>
> With setup now being stricter about versions wrt upgrading, we need to
> be as well. Because this is a post-2.49 revision, it should be
> VERSION=2.49 and RELEASE=2.YYYYMMDDhg15623 (since there was already a
> -1).
Version numbers like the one Ken has proposed are becoming common in
Linux distributions, so we'd rather check that setup handles them
correctly. I think Jari already uses a bunch of them. The thing here
is that for all versioning schemes that use hashes you need to prepend
an ISO date so things sort correctly, but I'd rather not append this to
the release number, so I'd suggest VERSION=2.49+YYYYMMDDhg15623 instead.
Also, I don't think it's a good idea to allow "." in the release
number. Alphas already work in that place (I use that for snapshots
since years) and are a lot less ambigous if you try to parse the release
out of a file name.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra