Date: Sat, 07 Mar 2020 04:35:32 +0000 From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 237971] sysutils/py-salt: split port into -latest and -stable (2019.2 and 2018.3) Message-ID: <bug-237971-21822-WDhFS6LeSE@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-237971-21822@https.bugs.freebsd.org/bugzilla/> References: <bug-237971-21822@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237971 --- Comment #6 from Ben Woods <woodsb02@freebsd.org> --- Hi Christer, Now that phase 3 upstream support is now finished for 2018.3, can I ask what you would like to do with this bug? https://www.saltstack.com/product-support-lifecycle/ >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 m= ake 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 comman= ds above). EXTRACT FROM UPSTREAM DOCUMENTATION - UPGRADE INSTRUCTIONS https://docs.saltstack.com/en/master/topics/installation/index.html#upgradi= ng-salt " Upgrading Salt 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 minio= ns will be preserved. Generally, the only exception to this policy is in case = of a security vulnerability. " --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237971-21822-WDhFS6LeSE>