"If we are to de-prioritise the new API at the cost of further development of legacy APIs then we are prolonging the period of time in which we request developers to use an API which we are intending to discontinue."
I don't disagree. But if we de-prioritize the old API at the cost of furthering the development of new API then we are encouraging the development of unstable apis that are not complete and won't have a stable release for X amount of time. Which isn't exactly ideal either. I don't think either option sounds great and it's going to get to a point of "Don't use that api, it will be discontinued, but don't use that api either because it is unstable, incomplete, and will change". New developers will look at that say... uh... okay so what do I use? Something other than EFL. On Mon, Dec 18, 2017 at 10:04 AM Andrew Williams <a...@andywilliams.me> wrote: > Hi, > > Apologies I was using "legacy" by way of definition to separate it from > "unified" APIs. > We are now fighting a battle of multiple focuses - Some tell me that we > are pushing the Unified / interfaces as fast as we can and anything (such > as release) would slow us down. Others are reporting that legacy is our > main area of development. > I am confused. If I am confused then anyone coming to the project surely > would be too. > If we are to de-prioritise the new API at the cost of further development > of legacy APIs then we are prolonging the period of time in which we > request developers to use an API which we are intending to discontinue. > > Whether you think that the development of BETA is skewing the results > there is the remaining issue that our "stable" API appears to have had a > total of 45 page hits in 2 weeks. > > I wonder if we have any metrics on the number of users relying on the > existing API (outside of our own apps). > > Andrew > > On Mon, 18 Dec 2017 at 15:44 Stephen Houston <smhousto...@gmail.com> > wrote: > >> I disagree with #1. It's not Legacy API until it is actually, you know, >> legacy. Who knows how long the "beta" api will be before released and how >> long it will be until there is a stable release of it that will work full >> featured for application, especially elementary, development. To not >> provide improved docs with the legacy api, is to say that the primary way >> developers can get involved over the next couple years, the legacy api, >> isn't worth anything. All current apps, including Enlightenment, are using >> the legacy api, because that is what is stable, and that is how we are >> still going to get people involved for the foreseeable future (unless they >> are interested in working on the actual beta api implementation). If >> anything I would argue that the focus should be more on the legacy api than >> the beta api, since no one uses the beta api, and it isn't stable. Just a >> personal take. I would venture to say a big reason the hits are coming in >> more on the beta api is because that is currently receiving the majority of >> the active development and you are getting hits from those developers. >> >> On Mon, Dec 18, 2017 at 6:23 AM Andrew Williams via >> Efl-technical-documentation <efl-technical-documentat...@lists.s-osg.org> >> wrote: >> >>> Hi all. >>> >>> Since adding Google Analytics a while back I have some interesting >>> statistics that I thought I would share: >>> >>> 1) Very few people read our Stable API documentation - around 0.5% of >>> our page hits >>> 2) Over 5% of the page hits are already for the beta API documentation >>> 3) Most of the hits to /docs seem to result in a referral to /develop >>> 4) Nearly 40% of people landing on our home page leave right away >>> 5) Terminology is the most popular app (by page hits) and Edi is second >>> (1/4 times the hits) then ephoto (1/4 again) >>> >>> Not all of this requires any action but here is the action plan: >>> 1) I am not intending to put any further effort into our legacy API >>> other than the extraction of eina and eo for the Beta API docs >>> 2) We can expect more people to be trying to use our Beta API - do we >>> need to prepare for this or should we put up more obvious warnings about >>> attempting? >>> 3) I think it is time that the main "Develop" link goes to the /develop/ >>> dokuwiki. The link to phab exists on the /contrib page where it belongs >>> 4) We should find a way to make our home page more appealing - when >>> loaded on an average monitor you need to be full screen to see anything >>> more than the "Window manager" section. >>> 5) For our about page we may need to tell a better story about how it >>> all fits together. Otherwise it's E & EFL and a list of apps - not the how >>> or why of what we are doing... >>> >>> Please shout if you disagree with any of these action points :) >>> >>> Andrew >>> -- >>> http://andywilliams.me >>> http://ajwillia.ms >>> >> _______________________________________________ >>> Efl-technical-documentation mailing list >>> efl-technical-documentat...@lists.s-osg.org >>> http://lists.s-osg.org/listinfo/efl-technical-documentation >>> >> -- > http://andywilliams.me > http://ajwillia.ms > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
