On Fri, Aug 10, 2018 at 03:57:31PM +0200, Shawn Rutledge wrote: > On 10 Aug 2018, at 15:14, Oswald Buddenhagen <oswald.buddenha...@qt.io> wrote: > > secondly, as your own caveat highlights, you need to encode and > > maintain policy in the script to make that work. > > Starting to use the Fixes: tag at all is a policy, and writing code > that reacts to it amounts to encoding a policy. It’s not the first > script which does something like that. > yes, but it's bad engineering to hard-code the policy if it's implicitly available from somewhere else as data.
> > thirdly, your proposed heuristics are wrong, because there is a window > > of time where changes integrated into dev do *not* target the next minor > > release (or a pre-release thereof): the time between the final downmerge > > form dev and the actual release. > > The window between the first creation of a new branch (on Monday) and > the final merge from dev to that branch (a week from Monday) is more > of a concern; > during that time we have a 5.12 branch (assuming we check the highest > branch rather than tag) but changes to dev are still for 5.12. > that's completely true. how is that a concern? > Maybe read .qmake.conf then? > you just topped yourself: now we not only read the git repo's meta data, but also its content, to extract data in a format that is bound to the current version of a certain subset of the repositories. also, this won't work, because the contents of these files intentionally lag the downmerges - just in case somebody comes to request another downmerge in some repo, because they've been living under a rock and missed the deadline (happens on a somewhat regular basis). _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
