From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5212 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl 1.0.x branch Date: Mon, 9 Jun 2014 16:08:30 -0400 Message-ID: <20140609200830.GK179@brightrain.aerifal.cx> References: <20140606175617.GA3914@brightrain.aerifal.cx> <20140609112352.1e7ad51e@ncopa-desktop.alpinelinux.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1402344539 7494 80.91.229.3 (9 Jun 2014 20:08:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Jun 2014 20:08:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5217-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 09 22:08:52 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Wu5s3-0004w1-VI for gllmg-musl@plane.gmane.org; Mon, 09 Jun 2014 22:08:44 +0200 Original-Received: (qmail 1945 invoked by uid 550); 9 Jun 2014 20:08:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1934 invoked from network); 9 Jun 2014 20:08:42 -0000 Content-Disposition: inline In-Reply-To: <20140609112352.1e7ad51e@ncopa-desktop.alpinelinux.org> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5212 Archived-At: On Mon, Jun 09, 2014 at 11:23:52AM +0200, Natanael Copa wrote: > On Fri, 6 Jun 2014 13:56:17 -0400 > Rich Felker wrote: > > > I'm about to prepare the 1.0.3 release, and I've been thinking a bit > > about the future of the 1.0.x branch. Specifically I'd like to gauge > > the extent to which it's being used. So far cherry-picking fixes to it > > has been pretty easy, but it's an extra task to keep up with, and the > > cherry-picking is probably going to turn into active backporting > > somewhere in the near future as the rs-1.0 and master branches > > continue to diverge. > > > > If I don't hear back that there's significant use of the 1.0.x > > releases by multiple projects, I'll probably plan to discontinue them > > in the next 4 to 6 months, and in the mean time, to release only when > > there are serious bugs (as opposed to releasing alongside every 1.1.x > > release). Does this sound reasonable? > > Yes. I guess you could just drop 1.0.x support now and consider re-open > it if you get complains. That's roughly what I proposed doing for now, except for throwing out a release without anyone complaining/requesting it in cases where there's a major bug (mainly just CVE-worthy ones, I think). > > If anyone's using 1.0.x not for the sake of stability but because it > > works better in some way for your setup (e.g. size, performance, > > application compatibility, etc.) please let me know about that too so > > we can see if there's a reasonable way to make 1.1.x work just as well > > for you. > > Alpine Linux appreciate the idea of stable/maintenance branches, but we > figured that we'd be better off with the 1.1.x for out 3.0 stable > release. (which is kinda beta anyways). We need the new features. Yes. In hindsight 1.0 was probably slightly premature from a "ready for distros" perspective, but releasing it as "1.0" was also probably essential to discovering that. So at this point if the 1.0.x branch is useful to anyone, I suspect it's users who have musl in embedded products where they know it meets their needs already and don't want to risk big changes, rather than distro-type users. I'd actually be interested in looking at other approaches for next time we reach a poing of needing a "new stable series" -- something to avoid unbounded divergence between stable and master. Having a rolling "well-tested and believed stable except for known bugs X, Y, and Z" release that's a few versions behind the latest release, and a list of commits since then which are purely bug-fixes, might be a good practical option. Such pairs of (base-version,list-of-commits) could automatically be transformed into tarballs. Rich