This is the mail archive of the
mailing list for the Cygwin project.
Re: Question about clisp version naming
- From: Ken Brown <kbrown at cornell dot edu>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 13 Mar 2015 12:37:00 -0400
- 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> <874mpq4sxr dot fsf at Rainer dot invalid>
On 3/12/2015 2:43 AM, Achim Gratz wrote:
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
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.
Sorry, but Yaakov says we already allow dots in the release number, and
he's the distro czar. So I'm going with his suggestion.