This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 2.22.1 Possible


Thanks for the explanation.

> > Is there any reason why such significant things didn't go into 2.22.1
> > and 2.22.2 and so on as they were found and resolved? (with matching
> > ports to trunk, of course)
> Backporting to the branch is done on request of the maintainers or the
> patch submitter.
> I think this is a very sane and safe approach, and was the tradition.

Agreed, but I meant "as they were found and resolved <i>in the 2.22
branch</i>", which presumably happened over a wide-ish period of time.

> > is there a concern for flooding downstreams with too many releases? or
> > what?
> In anycase, I don't think we want too many releases. ?I think that one
> yearly major release and
> one minor release within the next 6 months makes sense.

I'm a big fan of release when ready, but the point wasn't about new
features/code/archs, it was more about bug fix releases to existing
releases. In anything I've ever been involved with, those go out to
the user/customer/client/whoever as soon as humanly possible once
found, fixed, verified, tested. Hence the question about how much of a
pain it is. If it's too much of a pain, that negatively affects all
users not building direct from your trees with inside knowledge.

> ?At binutils is
> free software, anyone can
> build the release branch or the trunk.

Yes, that is of course true, but it's nice to have the experts stamp
of approval on it :-) Not having that makes it onerous and somewhat

I see another email :-) Excellent!



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]