Re: Where can I find detailed extension API changes of gnome-shell
- From: Stéphane ANCELOT <sancelot free fr>
- To: rastersoft <raster rastersoft com>, gnome-shell-list gnome org
- Subject: Re: Where can I find detailed extension API changes of gnome-shell
- Date: Sat, 16 May 2015 11:34:01 +0200
On 15/05/2015 10:37, rastersoft wrote:
Of course, I know that there still would be need in some cases to use
monkey patching, but trying to reduce its need to only the
really-really-need cases should reduce the review work.
On 15/05/15 10:33, rastersoft wrote:
Hi:
The extension review process is mostly for checking whether the
extension is malicious or not ... reviewers are free to check other
things like code quality, obvious bugs etc. but that depends on the
reviewer.
Yes, but with a stable API for the most common things, changes in the
internal structure of GS won't mean the need to modify extensions each
six months. And if the code doesn't change so often, then the code
reviews will be much less and the whole process be more fluid.
When my extensions worked directly, without changes, in a new GS
version, I just uploaded them with the same code but a new metadata.json
with the new list of valid versions, and they appeared automatically,
because a code review wasn't needed.
That was opinion in my mind.... This API may be a good concept, but very
bad management. No documentation API changes available....(or impossible
to find the right place to speak about it and have the answer...) . I
had a working extension using absolute positioning widget . The absolute
positioning has gone because one person decided there was a bad concept
somewhere. After months I finally found a bugreport telling why it has
been disabled... without providing workaround...after asking question ,
somebody gave me a workaround, I will try it.... I am not convinced it
will work ...
If you continue this way developers as myself will find a bad and quick
workaround :
leave gnome for something better documented and working in regards of
what I want to do !. that's would be a shame isn't it ?
I think API changes must :
Either permit backward compatibility using deprecated messages for a time.
follow a release change calendar, this is not possible to use an API
that changes every months in a production environment.
Each API changes must include a migrating guide .
Regards,
Steph
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]