From mboxrd@z Thu Jan 1 00:00:00 1970 X-Received: by 10.140.149.195 with SMTP id 186mr22588798qhv.0.1428395668894; Tue, 07 Apr 2015 01:34:28 -0700 (PDT) X-BeenThere: voidlinux@googlegroups.com Received: by 10.140.72.20 with SMTP id l20ls32940qgc.2.gmail; Tue, 07 Apr 2015 01:34:28 -0700 (PDT) X-Received: by 10.140.87.70 with SMTP id q64mr227522qgd.10.1428395668776; Tue, 07 Apr 2015 01:34:28 -0700 (PDT) Date: Tue, 7 Apr 2015 01:34:28 -0700 (PDT) From: =?UTF-8?Q?Stefan_M=C3=BChlinghaus?= To: voidlinux@googlegroups.com Message-Id: <7887d857-00a3-4e7b-9f5e-435612034ac5@googlegroups.com> In-Reply-To: References: Subject: Re: Void-Stable? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3422_612110453.1428395668405" ------=_Part_3422_612110453.1428395668405 Content-Type: multipart/alternative; boundary="----=_Part_3423_1293714441.1428395668406" ------=_Part_3423_1293714441.1428395668406 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I suppose someone could maintain a series of "stable" repositories that are (at time of creation) essentially copies of the main void repositories. A simple shell script could be used switch releases on the users system. Security updates may then simply be backported into previous releases. However, to ensure that updates between the releases do not break anything would be a HUGE commitment, very time-consuming and with limited resources (time, manpower) there is still always the possibility that some problems will be overlooked. An additional mechanism would probably need to be implemented to (semi)automatically deal with any update conflicts that cannot be avoided in the packages. At that point you would need to update step by step, one release at a time, even if your systems current state is several releases back. Otherwise every new release has to be tested/fixed for all supported prior releases, which would multiply the effort to do so. ------=_Part_3423_1293714441.1428395668406 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I suppose someone could maintain a series of "stable" repo= sitories that are (at time of creation) essentially copies of the main void= repositories. A simple shell script could be used switch releases on the u= sers system. Security updates may then simply be backported into previous r= eleases.

However, to ensure that updates between the rel= eases do not break anything would be a HUGE commitment, very time-consuming= and with limited resources (time, manpower) there is still always the poss= ibility that some problems will be overlooked. An additional mechanism woul= d probably need to be implemented to (semi)automatically deal with any upda= te conflicts that cannot be avoided in the packages.

At that point you would need to update step by step, one release at a ti= me, even if your systems current state is several releases back. Otherwise = every new release has to be tested/fixed for all supported prior releases, = which would multiply the effort to do so.
------=_Part_3423_1293714441.1428395668406-- ------=_Part_3422_612110453.1428395668405--