This is a change request. I am using portmaster to update my installed ports. Since some time, mozilla ports (firefox, libxul, thunderbird) are updated taking release candidates into account. While this has the advantage of quickly exposing new features to the general public, it also means that potentially unstable code is being distributed. Furthermore, this is done in a rather intransparent way, as one cannot deduce from the version designation that a release candidate has actually been installed. For example, today's update creates firefox-50.0,1 from firefox/candidates/50.0-candidates/build1/source/firefox-50.0.source.tar.xz and libxul-45.5.0 from firefox/candidates/45.5.0esr-candidates/build1/source/firefox-45.5.0esr.source.tar.xz. A further disadvantage is the rapid succession of new releases with little relevant changes requiring frequent updates. I therefore propose to split off -devel versions of these ports where users who want to stay on the bleeding edge are served the release candidates as is currently done on the main ports. The main ports themselves should revert to only upgrading to truly released versions. -- Martin
(In reply to Martin Birgmeier from comment #0) > While this has the advantage of quickly exposing new features to the > general public, It also means quickly fixing security vulnerabilities that upstream hasn't yet published but the bad guys may already be using or can deduce from individual commits. > it also means that potentially unstable code is being distributed. Such code can end up in releases as well, otherwise there'd be only one major version each iteration (6 weeks). Not to mention any major Firefox release is potentially unstable because upstream considers FreeBSD a Tier3 platform i.e., no one is assigned to check for our regressions. And I'm not interested in debugging broken builds, crashes or runtime regressions specific to old versions. If you want the most stability maybe switch to www/firefox-esr. > Furthermore, this is done in a rather intransparent way, as one cannot > deduce from the version designation that a release candidate has > actually been installed. A release candidate may be promoted to an actual release in which case the distfile wouldn't change, so the package has to stay the same. If a new one appears before release, PORTREVISION is bumped. So, users shouldn't try to deduce versions in order to skip some but upgrade packages regularly. > A further disadvantage is the rapid succession of new releases with little > relevant changes requiring frequent updates. www/firefox has PORTREVISION bumped often for other reasons as well e.g., 49.* had ports r421532 ports r422464, ports r422465, ports r422711, ports r422956 or ports r423591. Our quaterly branches (e.g. 2016Q4) are better suited for users that want less frequent updates. But thanks for reminding me I shouldn't merge candidates there. www/firefox-esr rarely has non-build1 candidates as ESR branch isn't supposed to carry anything but bug and security fixes. If it has more candidates then something was rushed through upstream QA process which makes the update more risky. > I therefore propose to split off -devel versions of these ports where > users who want to stay on the bleeding edge are served the release > candidates as is currently done on the main ports. The main ports > themselves should revert to only upgrading to truly released versions. -devel suffix is for ports that snapshot development branch i.e., mozilla-central in this case. What you probably meant is -beta but release candidates are more are of its own flavor. However, I don't plan to create new gecko@ ports as it'd increase maintenance. Some refactoring needs to happen first in order to increase bus factor and expand the team.
Thank you for these remarks. I understand that maintaining separate -beta ports is too time-consuming. Maybe it would still be possible to just not include the release candidates in the release cycles for these ports as was done previously, or maybe add a flag which allows to easily skip upgrading of the port as long as it is based on a release candidate - although that might need a change in the port make infrastructure (and probably portmaster, too). In any case I want to add that I really appreciate how well these essential ports are maintained, and how quickly you resolve any issues (I submitted one myself not too long ago). -- Martin
Seems answered. Could this closed?
Maintainer does not like the idea, so let's close this PR.