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 _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
