Future frameworks releases

Christian Mollekopf chrigi_1 at fastmail.fm
Tue Jun 16 09:33:05 UTC 2015



On Thu, Jun 11, 2015, at 08:20 PM, Sebastian Kügler wrote:
> On Tuesday, June 09, 2015 10:39:58 Christian Mollekopf wrote:
> > On Monday 08 June 2015 11:21:56 Benjamin Reed wrote:
> > > On 6/8/15 11:02 AM, Eric Hameleers wrote:
> > > > The only sane way forward is that every Frameworks release contains
> > > > all Frameworks tarballs, regardless of updates since the previous
> > > > public release. Every Framework should adhere to the overall version
> > > > number.
> > >
> > > Yeah, this proposal makes no sense to me.  If you want to individually
> > > manage a library with an independent numbering scheme, then shouldn't it
> > > be a separate/external project?  The whole point of the "framework" is
> > > to provide a monolithic thing that has everything you need.
> > 
> > If that's the point of frameworks, being that monolithic thing, then indeed 
> > you are right. But I really hope it isn't.
> 
> It's not about being monolithic, it's about stable and reliable
> interfaces, version numbers and APIs are a big part of that, and that's why
> frameworks can't just be removed and added back from one release to another, and why 
> version numbers need to be consistent across the whole set of frameworks.
> 

I understand your point about stability and reliability, but I just
don't think having the same version
for everything helps at all with that aim.

> Introducing exceptions increases the complexity of dealing with
> frameworks, their value really is in shared processes and requirements.
> 

True, but that's a tradeoff that I think is entirely worth making. The
complexity IMO
doesn't increase a lot, and the benefits of being more attractive to
maintainers and
getting higher quality frameworks far outweigh that (IMHO of course).

> I am strongly against watering it down. If some library is better off
> with its own versioning scheme and release process, then it simply should not be
> part of our Frameworks releases, but something else (which is entirely
> possible, still).

That, too me, just reduces the value of frameworks a lot. From my
perspective
that would mean every framework that has maintainer that does release
management
(something good for the quality of it), should live outside of
frameworks.

Cheers,
Christian


More information about the release-team mailing list