From owner-freebsd-ports@freebsd.org Mon Jun 26 10:42:21 2017 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0A51DA6A5F for ; Mon, 26 Jun 2017 10:42:21 +0000 (UTC) (envelope-from mailinglists@toco-domains.de) Received: from toco-domains.de (mail.toco-domains.de [IPv6:2a01:4f8:150:50a5::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55B4773261 for ; Mon, 26 Jun 2017 10:42:21 +0000 (UTC) (envelope-from mailinglists@toco-domains.de) Received: from [192.168.0.111] (port-212-202-156-99.static.qsc.de [212.202.156.99]) by toco-domains.de (Postfix) with ESMTPA id 128E01AAF068; Mon, 26 Jun 2017 12:42:19 +0200 (CEST) Subject: Re: [RFC] Why FreeBSD ports should have branches by OS version To: David Demelier , freebsd-ports@freebsd.org References: From: Torsten Zuehlsdorff Message-ID: <2f23f3d0-dcb1-dc12-eb9f-c8966a10f5f7@toco-domains.de> Date: Mon, 26 Jun 2017 09:24:17 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 10:42:21 -0000 Aloha David, > I think the current process of having rolling-releases packages makes > unpredictable upgrades as we have to manually check if the upgrade > will be fine or not. When a user installs FreeBSD 11.0 on its system, > it probably expects that everything will work fine until a next major > upgrade like 12.0. That's why I think we really should implement > branches for a specific FreeBSD version. > > When FreeBSD 12.0 is released, we should create a ports branch that > will contains only fixes (such as security advisories, crash fixes and > such). No minor or major upgrades until a new 13.0 version is > released. This is the only way to make safe upgrades. The discussions did go on for a while, but lets get more technical. While i can understand your use case, it raises various questions: - How should be EOL-Software handled? For example PHP 5.6, Typo3 7, PostgreSQL 9.2 and many more will expire long before FreeBSD 11 expires but are still valid (or even default version) when created. Since the versions are frozen, how should - at least- security issues handled? [Yes, i read that a user can switch at its own risk to another branch, but lets assume he is very fine with the version (because i have such customer)] - How should be new dependencies handled? GitLab for example sometimes *requieres* updates of its dependencies in order to fix security issues. - Same as above: how should be dropped dependencies handled? In worst case we need to maintain them for nearly 5 years, but nobody (should) use them - How to resolve conflicts? I mentioned GitLab above and now realize, that sometimes the GitLab update breaks for example www/redmine because it depends at other versions than GitLab. - Where do get the fixes from? We have around 26.000 ports which needs fixes in worst case - How to handle for example security issues only fixed through an update? Which such a long time between "updates" it gets very very hard to port/get/write patches in fast developing software. Wordpress or Gitlab are typical examples with thousands of lines in code-changes every update - How to make the customer clear, that complains about the software (old, outdated, missing features, unresolved bugs, etc) are intentional? - Where to archive the distfiles? Sometimes upstream completely remove them from everywhere they can. And last: how to make updates from FreeBSD version to version easier? Many user already have problems with single major updates. From my experiences in Windows or Ubuntu LTS usages with such or very similar version handling: the update, even of the OS, is pushed as far away as possible, because of the big amount of work required, since everything needs to checked/updated/changed. I have a hard time to image, that is handled in another way by you. So if you can me give more insight about your use-case i would be happy to read it for a better understanding. I have various customer requiring (and paying for) very old software (for example still PHP 5.3). So i know some of there motivations, which boils every time down to "its to expensive to upgrade our software" [but they don't mean expensive in money]. So maybe we can make something happen. Greetings, Torsten