Created attachment 204450 [details]
Per conversation in bug #236054, I am attempting to split the port into -latest and -stable versions. At this time that will represent the 2019.2.x and 2018.3.x branches respectively.
Attached are patches for sysutils/py-salt20183, sysutils/py-salt20192.
These have been tested on @py27 and @py36 versions.
The default version should probably be sysutils/py-salt20183.
Created attachment 204451 [details]
Created attachment 204452 [details]
Created attachment 204453 [details]
Created attachment 204454 [details]
Created attachment 204455 [details]
Now that phase 3 upstream support is now finished for 2018.3, can I ask what you would like to do with this bug?
From a user's point of view, its always nice if you can just keep doing "pkg upgrade", and not have to worry about versions. Am I correct in saying this patch would require the following manual steps from users to upgrade between versions?
# pkg remove py37-salt20183
# pkg install py37-salt20192
Given salt masters and minions should generally be kept in sync, it might make sense for salt to have separate packages in this case, and give the sysadmin fine-grained control over the salt versions being run (using the pkg commands above).
EXTRACT FROM UPSTREAM DOCUMENTATION - UPGRADE INSTRUCTIONS
When upgrading Salt, the master(s) should always be upgraded first. Backward compatibility for minions running newer versions of salt than their masters is not guaranteed.
Whenever possible, backward compatibility between new masters and old minions will be preserved. Generally, the only exception to this policy is in case of a security vulnerability.