Future frameworks releases

[Christian Mollekopf]

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