From mboxrd@z Thu Jan 1 00:00:00 1970 X-Received: by 10.50.20.135 with SMTP id n7mr1287482ige.8.1428366884568; Mon, 06 Apr 2015 17:34:44 -0700 (PDT) X-BeenThere: voidlinux@googlegroups.com Received: by 10.182.252.106 with SMTP id zr10ls976509obc.57.gmail; Mon, 06 Apr 2015 17:34:44 -0700 (PDT) X-Received: by 10.182.22.134 with SMTP id d6mr113448obf.41.1428366884342; Mon, 06 Apr 2015 17:34:44 -0700 (PDT) Date: Mon, 6 Apr 2015 17:34:43 -0700 (PDT) From: Kevin Berry To: voidlinux@googlegroups.com Message-Id: <528fece0-4ba2-448b-b20f-f5fb18324d32@googlegroups.com> In-Reply-To: References: Subject: Re: Void-Stable? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_921_892925249.1428366883772" ------=_Part_921_892925249.1428366883772 Content-Type: multipart/alternative; boundary="----=_Part_922_778934707.1428366883772" ------=_Part_922_778934707.1428366883772 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I'd definitely like this sort of thing. I love Void as a distro, but I can't sanely use a rolling release distribution for my production servers without some kind of safe upgrade path, similar to how Ubuntu snapshots every 6 months. Ideally, support short exist for security updates for a year from a patch level, me thinks. On Monday, April 6, 2015 at 6:16:05 PM UTC-5, bougyman wrote: > > > With the existence of the void daily package archive, I've been bouncing > around an idea about how someone (some admin/architect/enterprise) could > maintain > their own 'stable' release cycle of void. If upon initial configuration > the repos are set to an archive with a date stamp, and the user has a way > to validate that moving > from that datestamp to ### future datestamp doesn't (potentially) break > any functionality, they can safely choose an upgrade path. for instance. > > I install on 2015-03-26 and lock the repository to the archive snapshot of > that date > > on 2015-04-26 I run *magic-command* and ask if upgrading to current > (2015-04-26) would (potentially) break any installed packages. > > I get output about any important breaking changes (to xbps, etc) which may > require an 'upgrade this first' action or 'remove these' actions. > I get output that may just say: 'Upgrade to 2015-04-01 first, then to > 2015-04-15, then 2015-04-26' (or does this automagically?) > > Thoughts? > > bougy > ------=_Part_922_778934707.1428366883772 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'd definitely like this sort of thing.  I love Void = as a distro, but I can't sanely use a rolling release distribution for my p= roduction servers without some kind of safe upgrade path, similar to how Ub= untu snapshots every 6 months.  Ideally, support short exist for secur= ity updates for a year from a patch level, me thinks.

On Monday, Apr= il 6, 2015 at 6:16:05 PM UTC-5, bougyman wrote:

  With the existence of the= void daily package archive, I've been bouncing around an idea about how so= meone (some admin/architect/enterprise) could maintain
their own = 'stable' release cycle of void. If upon initial configuration the repos are= set to an archive with a date stamp, and the user has a way to validate th= at moving
from that datestamp to ### future datestamp doesn't (po= tentially) break any functionality, they can safely choose an upgrade path.= for instance.

I install on 2015-03-26 and lock th= e repository to the archive snapshot of that date

= on 2015-04-26 I run *magic-command* and ask if upgrading to current (2015-0= 4-26) would (potentially) break any installed packages.

I get output about any important breaking changes (to xbps, etc) whic= h may require an 'upgrade this first' action or 'remove these' actions.
I get output that may just say: 'Upgrade to 2015-04-01 first, then t= o 2015-04-15, then 2015-04-26' (or does this automagically?)

=
Thoughts?

bougy
------=_Part_922_778934707.1428366883772-- ------=_Part_921_892925249.1428366883772--