This is the mail archive of the
mailing list for the Cygwin project.
Re: per-version hints proposal
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: cygwin-apps at cygwin dot com
- Date: Tue, 21 Jun 2016 19:26:53 +0100
- Subject: Re: per-version hints proposal
- Authentication-results: sourceware.org; auth=none
- References: <8b4723b2-1bd5-3604-1deb-cfd0a1c7b9d9 at dronecode dot org dot uk> <20160621120321 dot GL3667 at calimero dot vinschen dot de>
On 21/06/2016 13:03, Corinna Vinschen wrote:
On Jun 20 16:28, Jon Turney wrote:
* 'curr', 'prev' and 'test' don't make sense on a per-version basis. So I
suggest a separate file for these version overrides (versions.hint?)
Ideally we wouldn't need something like "prev" at all since the version
number itself is sufficient to specify what's curr and what's old.
As for test, IMHO it would make sense to specify "this is a test
release" right in the cygport file. This in turn could create a
per-version hint with a test marker which is evaluated by calm
accordingly. For instance, the name of the file could take over this
role. Or even better, the package version number itself.
This would have an additional benefit: We couldn't just move a package
from test to curr, it would have to be explicitely rebuilt as non-test
I think this is the cleanest solution.
I'm not sure I agree with this reasoning.
Without control over the other elements which determine the build
product (e.g. compiler version, headers, static libraries, etc.), there
is the risk that any testing you have done on the test package is
invalidated when it is rebuilt.
Otoh, if you did have perfect build reproducibility, you are rebuilding
the package just to change a label applied to it, which seems a bit
I take the point that 'test' could be more useful, but I think that's
out of scope of what I want to achieve, for the moment.