From: Jon Turney <jon.turney@dronecode.org.uk>
To: cygwin-apps@cygwin.com
Subject: Re: per-version hints proposal
Date: Tue, 21 Jun 2016 18:27:00 -0000 [thread overview]
Message-ID: <edd8ee26-e482-5f67-efa7-2687ebe60002@dronecode.org.uk> (raw)
In-Reply-To: <20160621120321.GL3667@calimero.vinschen.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
> 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.
next prev parent reply other threads:[~2016-06-21 18:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 15:28 Jon Turney
2016-06-21 12:03 ` Corinna Vinschen
2016-06-21 13:49 ` Marco Atzeri
2016-06-21 14:28 ` Corinna Vinschen
2016-06-21 15:32 ` Marco Atzeri
2016-06-21 14:09 ` Eric Blake
2016-06-21 14:27 ` Corinna Vinschen
2016-06-21 18:04 ` Achim Gratz
2016-06-21 18:27 ` Jon Turney [this message]
2016-08-30 12:24 ` Jon Turney
2016-08-31 19:14 ` Achim Gratz
2016-09-01 17:15 ` Jon Turney
2016-12-08 19:30 ` Jon Turney
2016-12-09 10:46 ` Corinna Vinschen
2016-12-09 11:10 ` Corinna Vinschen
2016-12-12 13:29 ` Jon Turney
2016-12-12 13:29 ` Jon Turney
2017-04-08 17:00 ` Achim Gratz
2017-04-12 20:51 ` Ken Brown
2017-04-13 6:24 ` Achim Gratz
2016-09-17 6:15 ` Achim Gratz
2016-09-18 5:17 ` Marco Atzeri
2016-09-18 15:14 ` Jon Turney
2016-09-18 16:12 ` Achim Gratz
2016-09-18 16:29 ` Achim Gratz
2016-09-19 15:37 ` Ken Brown
2016-09-19 18:24 ` Achim Gratz
2016-09-19 22:23 ` Jon Turney
2016-09-18 16:40 ` Ken Brown
2016-09-18 16:53 ` Marco Atzeri
2016-09-18 17:16 ` Achim Gratz
2016-09-18 18:08 ` Marco Atzeri
2016-09-22 13:44 ` Eric Blake
2016-12-10 22:42 ` How to override previous version? David Rothenberger
2016-12-11 0:03 ` Jon Turney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=edd8ee26-e482-5f67-efa7-2687ebe60002@dronecode.org.uk \
--to=jon.turney@dronecode.org.uk \
--cc=cygwin-apps@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).