El Dimarts, 19 d'agost de 2014, a les 08:44:10, David Faure va escriure: > On Friday 15 August 2014 12:51:58 Kevin Ottens wrote: > > On Friday 15 August 2014 09:34:04 Alex Merry wrote: > > > 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. > > > > And that's the problem if we release them. If it's released "with the > > rest" > > expect people to have wrong expectations about them. > > > > A possibility would be perhaps to produce nightly tarballs for those > > frameworks which don't have the "release: true" flag. This way they keep > > not being part of a release, and early adopters have something easy to > > grab. > Wouldn't early adopters just checkout and build from git ? > > I don't know about you, but I almost never download a source tarball, > because a git checkout is just so much easier to update later. > We mostly make tarballs for packagers, and the non-mature frameworks we're > talking about should definitely NOT be packaged. > > IMHO the solution is just to publicize the upcoming frameworks somewhere.
I see a small problem with git-only repos, and it's called release+distributions. I have heard that the plam is to frameworks-ize kdepimlibs, ideally one would like to do a release of kdepimlibs so that the kf5-based kdepim can use them but without guaranteeing ABI/API compatibility. But if we want distros to package that kdepim we're going to need packages. Cheers, Albert _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
