Re: per-version hints proposal

[Jon Turney <jon dot turney at dronecode dot org dot uk>]

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