Il 29/01/20 09:52, Cristián Maureira-Fredes ha scritto: >> Regarding the LTS decision, you can take it from another point of >> view: 5.15 will only have 2 or 3 bug fixing releases, and so will all >> the LTS versions in the future. Since TQtC has commercial costumers, >> we will internally fork the latest bug fix release, and will start >> adding patches on top of that on request of the costumers, but hey! >> all those patches will be on Gerrit, so if they are important for >> your work, you can just cherry pick them to your local Qt and >> re-build.
Giuseppe D'Angelo (29 January 2020 10:36) ha scritto: > Ok, finally some answers here. > > I don't understand this model at all: if in the long run 5.15 is going > to be maintained as a private fork, but all the patches to it are > going to be public on gerrit, it's going to take approximately 20 > minutes for someone to > * set up a gerrit stream > * get all the merged patches targeting this "5.15-private" branch > * cherry pick them on 5.15.x > * publish the result (5.15.oss-latest) on github or KDE or so Clarification: we'll be moving to "all commits land first on dev and are cherry-picked out to other branches that need them" in place of our present merge-based module. Where Cristián says "all those patches will be on Gerrit", they'll be on dev on Gerrit. They'll be cherry-picked from there to a (presumably) private branch (maybe on a private repo), so you won't necessarily see the cherry-picked versions, only the dev versions. So any time the cherry-pick requires adaptation to the LTS, those running the fork above would need to duplicate the adaptation. Not claiming this contradicts the general thrust of your case, just clarifying what that case would mean in practice. Eddy. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development