On Friday 15 August 2014 10:21:57 Mark Gaiser wrote: > On Fri, Aug 15, 2014 at 12:12 AM, Àlex Fiestas <afies...@kde.org> wrote: > > Hi there > > > > At the Randa sprint we have discussed a little bit what to do with those > > frameworks that are still not mature (for example they can't commit on > > ABI/API stability) but they are ready for feedback from third party > > developers. > > > > Even though there was not consensus in the discussion this is an idea that > > came out during the discussion: > > > > -We introduce a Maturity level that we can use to manage expectations > > about > > the Framework (for example whether API/ABI will be kept) > > -We release Frameworks that are not ready together with the rest, but we > > have to make damn sure we manage expectations. > > > > With this we can get early feedback for new frameworks, and since we have > > a > > rapid release cycle we can improve them fast. > > > > What do you think? > > It depends on how you define maturity. > > For instance, if a maturity is simply a value set in each project' > metainfo.yaml and set by those that maintain it then the maturity > level quite frankly doesn't tell you anything. > > But if you decide maturity dynamically based on git activity, api/abi > stability, number of people contributing and where the project itself > is used in other projects (just some conditions that i can think of > now, there is probably more). With this a project maturity actually > has a meaning. When going for this approach it would also be nice to > show a list of projects using "Framework X". Also, i do not consider a > project being healthy when it has only one developer [1] even if the > project is used by dozens of other projects and has much activity. For > us - kde devs - we probably don't care much if a framework is being > developed/maintained by one person, but for external potential > framework users that will be a concern. Specially companies.
I think you're talking less about "maturity" and more about "vitality", or something. Anyway, naming aside, I think Àlex was talking specifically about API/ABI guarantees - we offer pretty strong guarantees, and fresh projects may not want to commit to that until they've had some real-world usage and feedback. This would allow the equivalent to kdelibs' old "experimental" tagging, which was used for a couple of libraries while they settled on an API. I think it could be useful, but would definitely require very careful communication. Alex _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
