Re: Where can I find detailed extension API changes of gnome-shell

[Stéphane ANCELOT <sancelot free fr>]

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