This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: per-version hints proposal

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 inefficient.

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]