On Mon, Oct 15, 2018 at 09:58:59AM +0100, Chris Jones wrote:
Hi,On 15/10/18 06:41, Joshua Root wrote:I agree with the points in Mojca's first message in the thread. On 2018-10-15 09:20 , Mojca Miklavec wrote:On Mon, 15 Oct 2018 at 00:10, Blair Zajac wrote:We could add a rule that should help a bit that openmaintainer only lets people do minor version bumps, e.g. X.Y to X.(Y+1) and X.Y.Z to X.Y.(Z+1). This doesn’t solve the Lua 5.2 to 5.3 one, but it would prevent the Python 2.7 to 3.7.This is pretty useless general strategy as a general rule because every project does the versioning in a different way. If we were to do it this way, then every single port would need to specify what precisely is allowed (to which versions it is ok to update).Perhaps we could add a checkbox for "I have verified that this update does not introduce any API or ABI incompatibilities." I expect contributors would be unlikely to check that off untruthfully.I think in practise that is also not possible to always be determined, nor I think should we make it a requirement of those submitting the PRs to do it, as all it would become is a barrier to people submitting contributions and we don't want that.In my opinion, if the version of the package being installed changes at all, the 72 hour timeout should apply.We also I think need a clear set of guidelines of exactly what sort of changes are allowed to be made without PR review, or sidestepping the 72 hour timeout . e.g.- Changes that cannot in any way alter the installed port. Like livecheck fixes, comments or descriptions.- rev-bumps just to rebuild against some other change. - Urgent bug fixes for otherwise broken ports.and so on... Do we have a guide for something like this written done anywhere ?
"7.4.1. Non-Maintainer Port Updates" in our guide. https://guide.macports.org/#project.update-policies.nonmaintainer
Chris- Josh
-- Zero
smime.p7s
Description: S/MIME cryptographic signature
