On Wed, 2020-09-16 at 10:26 +0200, Ulrich Mueller wrote: > > > > > > On Wed, 16 Sep 2020, Michał Górny wrote: > > It has two advantages: > > 1. It reduces the risk of accidentally leaving it in the stable ebuild. > > Huh, you mean you would remove the PROPERTIES token again, after the > version has been stabilised? Why?
No, I mean removing it when bumping from version unsuitable to
be a stable candidate to one that is suitable. What's really
problematic is that this mistake will be easy to miss, especially if
someone relies on pkgcheck entirely to determine when to stabilize
stuff.
>
> Ebuilds could do conditionals like this (again, an example that would
> work for app-editors/emacs):
>
> [[ ${PV//[0-9]} == "." ]] && PROPERTIES+="stablecandidate"
Yes, provided that developers will actually do that.
> > 2. It handles specifying multiple stabilization candidates on different
> > branches. I don't see how ebuilds would do that.
>
> I don't understand. Why couldn't PROPERTIES be specified in different
> slots?
>
How would you distinguish the ebuild group that represent the same
upstream branch (i.e. expecting only one report from the group) from
other upstream branches?
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
