Re: musl 1.0.x branch

[Rich Felker <dalias@libc.org>]

On Mon, Jun 09, 2014 at 11:23:52AM +0200, Natanael Copa wrote:
> On Fri, 6 Jun 2014 13:56:17 -0400
> Rich Felker <dalias@libc.org> 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