Created attachment 202381 [details]
This patch updates sysutils/py-salt to 2019.2.0.
Upstream release notes:
Created attachment 202382 [details]
poudriere testport (sysutils/py-salt@py27)
Created attachment 202383 [details]
poudriere testport (sysutils/py-salt@py36)
A commit references this bug:
Date: Wed Feb 27 15:05:34 UTC 2019
New revision: 494060
sysutils/py-salt: Update to 2019.2.0
Changes this release:
Submitted by: Christer Edwards <firstname.lastname@example.org> (maintainer)
Committed - thanks!
Can we please split this port into -devel and stable versions? 2018.3.4 was also released this week and is a much more appropriate upgrade for most users right now. Saltstack have a poor reputation for releasing very buggy updates, particularly major releases. They do minimal testing on FreeBSD so almost every update has major regressions.
Can we split this port if you really want to move to cutting edge versions which haven't yet gone through a beta process?
I don’t think it would be fair to call this a -devel release, as it is the latest stable release from upstream.
You already have the option of using a more stable version, by using the ports quarterly branch, but obviously that means “more stable” versions of ALL ports. I personally feel the latest minor release of salt should always be updated to the quarterly branch.
It could be possible to have a py-salt-latest port, and a py-salt-stable port, but it doubles the overhead of maintaining the port. Up to the maintainer really.
I've been through this journey with salt for four years now. I can pretty much put money on 2019.2.0 being at best beta quality.
The problem with tracking the latest builds days after release is that we never get the opportunity to use 2018.3.4 which will be a much better experience for everyone. Personally I don't mind since we'll cut our own port, but I want salt to be popular and for people not to give up after hitting problems.
Current critical bugs: https://github.com/saltstack/salt/issues?q=is%3Aopen+is%3Aissue+label%3A2019.2.1 and its only been 48 hours.
One major release they broke pkgng on FreeBSD. Another they broke prereq dependency management.
Even waiting for 2019.2.1 would be a big help.
I tend to agree with Ari.
SaltStack's lack of testing on FreeBSD has been a thorn in my side since submitting the port in 2011. Believe me, I've talked to them about it (their HQ is local to me). They don't believe there is a commercial market on *BSD and simply don't want to expend resources for it.
I will create a port to track latest and stable. Ben, please verify what the preferred portname would be. -devel? -latest? -stable? With that info I'll work on a new port that tracks 2018.3.x.
One option is to have multiple ports called:
Which version is used by packages which depend on salt would be defined in the ports make.conf variable DEFAULT_VERSIONS= salt=2018.3
These would follow the upstream salt support lifecycle, and be deprecated and delted once “phase 3” support is ended:
That approach seems good and consistent with ports like https://www.freshports.org/www/apache24 and with their current policy it would appear that they are likely to have only 2-3 'live' versions at once.
I've started work on this.
sysutils/py-salt20183 will be py27 only.
sysutils/py-salt20192 will be py27/py36.
I plan to do some more testing tomorrow and hopefully have a patch in day or two.
Nice. I don't think you need to pull python36 from 20183. We've been using that combination for at least 6 months without issue.
salt 2018.3.x is quite stable with py36. It would be nice to have both with sysutils/py-salt20183 too.
This port-split has been submitted in bug #237971.