From mboxrd@z Thu Jan 1 00:00:00 1970 X-Received: by 10.66.97.10 with SMTP id dw10mr19857652pab.48.1428362166557; Mon, 06 Apr 2015 16:16:06 -0700 (PDT) X-BeenThere: voidlinux@googlegroups.com Received: by 10.182.63.109 with SMTP id f13ls982145obs.25.gmail; Mon, 06 Apr 2015 16:16:06 -0700 (PDT) X-Received: by 10.182.108.169 with SMTP id hl9mr115117obb.6.1428362166166; Mon, 06 Apr 2015 16:16:06 -0700 (PDT) Date: Mon, 6 Apr 2015 16:16:05 -0700 (PDT) From: bougyman To: voidlinux@googlegroups.com Message-Id: Subject: Void-Stable? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_881_551415482.1428362165736" ------=_Part_881_551415482.1428362165736 Content-Type: multipart/alternative; boundary="----=_Part_882_1248069169.1428362165737" ------=_Part_882_1248069169.1428362165737 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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_882_1248069169.1428362165737 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

  With the existence of the void daily packa= ge 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 archiv= e 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 t= he archive snapshot of that date

on 2015-04-26 I r= un *magic-command* and ask if upgrading to current (2015-04-26) would (pote= ntially) break any installed packages.

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

Though= ts?

bougy
------=_Part_882_1248069169.1428362165737-- ------=_Part_881_551415482.1428362165736--