How to promote less mature Frameworks?

[Kevin Ottens]

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 <afiestas at 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.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140815/fba8129e/attachment.sig>