From owner-freebsd-ports@freebsd.org Thu Jun 22 23:47:40 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 B4CDCD974DD for ; Thu, 22 Jun 2017 23:47:40 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from msa1.earth.yoonka.com (yoonka.com [88.98.225.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "msa1.earth.yoonka.com", Issuer "msa1.earth.yoonka.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BACB6F876 for ; Thu, 22 Jun 2017 23:47:39 +0000 (UTC) (envelope-from list1@gjunka.com) Received: from ultrabook.yoonka.com (x2f7ff2c.dyn.telefonica.de [2.247.255.44]) (authenticated bits=0) by msa1.earth.yoonka.com (8.15.2/8.15.2) with ESMTPSA id v5MNSQUM044190 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 22 Jun 2017 23:28:27 GMT (envelope-from list1@gjunka.com) X-Authentication-Warning: msa1.earth.yoonka.com: Host x2f7ff2c.dyn.telefonica.de [2.247.255.44] claimed to be ultrabook.yoonka.com Subject: Re: [RFC] Why FreeBSD ports should have branches by OS version To: freebsd-ports@freebsd.org References: <20170622121856.haikphjpvr6ofxn3@ivaldir.net> <775ba90e-a811-4cc8-a729-bdc0dad7774c@FreeBSD.org> <1tlnkc1l8md98dl3teqoab8ds3jutmvavc@4ax.com> From: Grzegorz Junka Message-ID: Date: Thu, 22 Jun 2017 23:28:20 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <1tlnkc1l8md98dl3teqoab8ds3jutmvavc@4ax.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB-large 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: Thu, 22 Jun 2017 23:47:40 -0000 On 22/06/2017 15:50, scratch65535@att.net wrote: > [Default] On Thu, 22 Jun 2017 15:38:53 +0100, Matthew Seaman > wrote: > >> On 2017/06/22 15:03, scratch65535@att.net wrote: >>> Why don't the same choices apply here? What am I missing? >> Two things: >> >> 1) It's progress in the development of the FreeBSD base system that >> drives the release cycle. The general state of the ports does not exert >> much influence on release frequency -- nor should it. > Still not getting it, I'm afraid. How often does the base > system undergo such drastic architecture changes that existing > ports won't run under it? I haven't really been monitoring the > situation, but I'd guess it's very seldom if only because such an > architectural change is a cursëd big job that can hardly ever be > justfied. > > I'd guess that most adults for whom systems are tools not toys > are not too dissimilar to me: I want to *use* my tools, not > spend time replacing them every quarter or even every year. As > long as they do the job and don't compromise the system, they're > fine by me. I have apps running under Win7 that were written for > W2K (and in one case NT, iirc), and they're just as useful today > as they were then. They do the job: why in the name of sanity > should I replace them? > Not sure how you use your tools or in which industry you work. Take front-end development for example. Chrome is releasing a new version every couple of days. Sure, I don't upgrade every release, but when I am developing a website, I want to test using the same version that my customers are using, which is the latest, since Chrome on Windows updates itself automatically. The same with new versions of Firefox. Often new versions of browsers require new versions of libraries to support new features (CSS/JavaScript). That requires new versions of compiler and transpilers. They may, in turn, require an updated version of node or npm. Take server-side development as another example. Erlang is releasing a new version of OTP every couple of weeks. Sure, I don't need a new version when supporting an old application, but I may need one when starting a new application. Especially that many libraries that I am going to use won't support Erlang older than a specific version. A similar story with C++ development, where the standard is being constantly developed and compilers are adding these features every release. Again, you may not need these new features, but a library that you need to use may require the new version. No matter how long you are going to maintain a specific version of ports with locked down versions of applications, there will surely come a time when you will need to upgrade. And for every user that time will be different. The current model is in my opinion the most common denominator - we can't maintain multiple branches with past versions so lets try to properly maintain one with current versions. Grzegorz