Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Roberto Galoppini]

2013/7/31 Andrea Pescetti 

> On 30/07/2013 Rob Weir wrote:
>
>  On Tue, Jul 30, 2013 at 9:30 AM, Roberto Galoppini wrote:
>>
>>> If your extension is compatible with AOO 4.0, please take a moment to
>>> update the extension's compatibility information so that end-users will
>>> know it works with the latest release. If your extension is not
>>> compatible
>>>
>>
>> Is it clear how to do this?  Is there any doc we should point them to for
>> this?
>>
>
> The best resource we have at the moment is Hanya's list of API changes, on
> the mwiki.
>
> I linked to it from
> http://wiki.openoffice.org/**wiki/Extensions/Extensions_**
> and_Apache_OpenOffice_4.0
>

I have updated the email's text accordingly, including also Rob's
suggestion about the title.
The emails have been sent already.

Roberto


>
> Due to the several messages already seen about this topic, I added the
> Extensions compatibility to the Release Notes at
> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
> AOO+4.0+Release+Notes
> giving also a link to the above page.
>
> Regards,
>   Andrea.
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Oliver-Rainer Wittmann]

Hi,

On 31.07.2013 13:12, Andrea Pescetti wrote:

On 30/07/2013 Rob Weir wrote:

On Tue, Jul 30, 2013 at 9:30 AM, Roberto Galoppini wrote:

If your extension is compatible with AOO 4.0, please take a moment to
update the extension's compatibility information so that end-users will
know it works with the latest release. If your extension is not
compatible


Is it clear how to do this?  Is there any doc we should point them to
for this?


The best resource we have at the moment is Hanya's list of API changes,
on the mwiki.

I linked to it from
http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0



I have added some words about the user profile migration which handles 
user-installed extensions.


Best regards, Oliver.



Due to the several messages already seen about this topic, I added the
Extensions compatibility to the Release Notes at
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes
giving also a link to the above page.

Regards,
   Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Andrea Pescetti]

On 30/07/2013 Rob Weir wrote:

On Tue, Jul 30, 2013 at 9:30 AM, Roberto Galoppini wrote:

If your extension is compatible with AOO 4.0, please take a moment to
update the extension's compatibility information so that end-users will
know it works with the latest release. If your extension is not compatible


Is it clear how to do this?  Is there any doc we should point them to for this?


The best resource we have at the moment is Hanya's list of API changes, 
on the mwiki.


I linked to it from
http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0

Due to the several messages already seen about this topic, I added the 
Extensions compatibility to the Release Notes at

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes
giving also a link to the above page.

Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Hagar Delest]

Top posting
Same as Rob.

Hagar

Le 30/07/2013 15:55, Rob Weir a écrit :


On Tue, Jul 30, 2013 at 9:30 AM, Roberto Galoppini
 wrote:

2013/7/29 Roberto Galoppini 





2013/7/27 Rob Weir 


On Sat, Jul 27, 2013 at 4:59 PM, Roberto Galoppini
 wrote:

2013/7/27 Rob Weir 


On Fri, Jul 26, 2013 at 5:59 PM, Hagar Delest <

hagar.del...@laposte.net>

wrote:

Le 26/07/2013 15:40, Roberto Galoppini a écrit :


A) a link to a version compatible with AOO 4.0 has been added for
http://extensions.openoffice.org/en/project/pdfimport and
http://extensions.openoffice.org/en/project/mysql_connector

B) 4.0" has been added to the list of possible compatibilities. For
example
http://extensions.openoffice.org/en/node/287/releases doesn't

enlist

4.0

among AOO compatible versions, while new extensions have that set,

see

for

example http://extensions.openoffice.org/en/node/5644/releases.

Note that it's up to the author to indicate his/her extension
compatibility
list, and he/she can update it without the need to upload the file

again.



But it means that the author has to be aware that there is a change

and

he

has to update the relevant field.
There is no script that could add the lack of compatibility if the

extension

has not been updated yet?




The lack of compatibility is somehow implicit if you read that a given
extension is compatible with OpenOffice 3.3 or AOO 3.4 and it doesn't
mention AOO 4.0. See below about how to make sure such info is

up-to-date.






For the record, in the case of the Lorem ipsum extension, the author

doesn't

seem to be willing to update it...



If an extension is essentially abandoned then it is only a matter of
time before it breaks.  Either that or we put ourselves into a
position where we can never evolve and improve our API.  We should
focus on the needs of active extension developers, not the inactive
ones.

This is what we did to keep extension authors in the loop:

1) We created a special mailing list, a...@openoffice.apache.org for
discussions about extensions.

2) We worked with SourceForge to send an email to all registered
extension authors to invite them to the new list.  This was done
before the *.openoffice.org email forwarder was shut down, so they all
should have received the note.



We might resend an email to all Extensions' authors re-inviting them to
subscribe to the API mailing-list and also inviting them to check if

their

extensions do work with AOO 4.0 and eventually update their extension

page

accordingly.

Does it sound like a plan?



Reminders are good.



So what do we want to tell them, does anyone want to craft a draft message
for AOOE authors?




Subject: About Apache OpenOffice New Release and Updating your Extension's
Compatibility Info

Dear OpenOffice.org Extensions author,



Maybe just "OpenOffice Extensions author"?



As you may have heard, Apache OpenOffice 4.0 is now out, and we'd like to
invite you to test your own extension and figure out if it is or is not
compatible with Apache OpenOffice 4.0 and its new APIs.

If your extension is compatible with AOO 4.0, please take a moment to
update the extension's compatibility information so that end-users will
know it works with the latest release. If your extension is not compatible


Is it clear how to do this?  Is there any doc we should point them to for this?


we'd encourage you to release a new version if you have time, or ask people
to help you with that at the API mailing-list (http://openoffice.apache
.org/mailing-lists.html#api-mailing-list-public).

How do you like this?



Good.

-Rob


Roberto





Roberto





-Rob



Roberto




3) We announce the 4.0 API changes on the API list and answered any
questions that came up.

True, not everyone is happy about the changes.  But we tried to ensure
that every active extension author was aware of the changes coming.

Regards,

-Rob


Hagar

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org

For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Tue, Jul 30, 2013 at 9:30 AM, Roberto Galoppini
 wrote:
> 2013/7/29 Roberto Galoppini 
>
>>
>>
>>
>> 2013/7/27 Rob Weir 
>>
>>> On Sat, Jul 27, 2013 at 4:59 PM, Roberto Galoppini
>>>  wrote:
>>> > 2013/7/27 Rob Weir 
>>> >
>>> >> On Fri, Jul 26, 2013 at 5:59 PM, Hagar Delest <
>>> hagar.del...@laposte.net>
>>> >> wrote:
>>> >> > Le 26/07/2013 15:40, Roberto Galoppini a écrit :
>>> >> >
>>> >> >> A) a link to a version compatible with AOO 4.0 has been added for
>>> >> >> http://extensions.openoffice.org/en/project/pdfimport and
>>> >> >> http://extensions.openoffice.org/en/project/mysql_connector
>>> >> >>
>>> >> >> B) 4.0" has been added to the list of possible compatibilities. For
>>> >> >> example
>>> >> >> http://extensions.openoffice.org/en/node/287/releases doesn't
>>> enlist
>>> >> 4.0
>>> >> >> among AOO compatible versions, while new extensions have that set,
>>> see
>>> >> for
>>> >> >> example http://extensions.openoffice.org/en/node/5644/releases.
>>> >> >>
>>> >> >> Note that it's up to the author to indicate his/her extension
>>> >> >> compatibility
>>> >> >> list, and he/she can update it without the need to upload the file
>>> >> again.
>>> >> >
>>> >> >
>>> >> > But it means that the author has to be aware that there is a change
>>> and
>>> >> he
>>> >> > has to update the relevant field.
>>> >> > There is no script that could add the lack of compatibility if the
>>> >> extension
>>> >> > has not been updated yet?
>>> >>
>>> >
>>> > The lack of compatibility is somehow implicit if you read that a given
>>> > extension is compatible with OpenOffice 3.3 or AOO 3.4 and it doesn't
>>> > mention AOO 4.0. See below about how to make sure such info is
>>> up-to-date.
>>> >
>>> >
>>> >
>>> >> >
>>> >> > For the record, in the case of the Lorem ipsum extension, the author
>>> >> doesn't
>>> >> > seem to be willing to update it...
>>> >> >
>>> >>
>>> >> If an extension is essentially abandoned then it is only a matter of
>>> >> time before it breaks.  Either that or we put ourselves into a
>>> >> position where we can never evolve and improve our API.  We should
>>> >> focus on the needs of active extension developers, not the inactive
>>> >> ones.
>>> >>
>>> >> This is what we did to keep extension authors in the loop:
>>> >>
>>> >> 1) We created a special mailing list, a...@openoffice.apache.org for
>>> >> discussions about extensions.
>>> >>
>>> >> 2) We worked with SourceForge to send an email to all registered
>>> >> extension authors to invite them to the new list.  This was done
>>> >> before the *.openoffice.org email forwarder was shut down, so they all
>>> >> should have received the note.
>>> >>
>>> >
>>> > We might resend an email to all Extensions' authors re-inviting them to
>>> > subscribe to the API mailing-list and also inviting them to check if
>>> their
>>> > extensions do work with AOO 4.0 and eventually update their extension
>>> page
>>> > accordingly.
>>> >
>>> > Does it sound like a plan?
>>> >
>>>
>>> Reminders are good.
>>>
>>
>> So what do we want to tell them, does anyone want to craft a draft message
>> for AOOE authors?
>>
>
>
> Subject: About Apache OpenOffice New Release and Updating your Extension's
> Compatibility Info
>
> Dear OpenOffice.org Extensions author,
>

Maybe just "OpenOffice Extensions author"?


> As you may have heard, Apache OpenOffice 4.0 is now out, and we'd like to
> invite you to test your own extension and figure out if it is or is not
> compatible with Apache OpenOffice 4.0 and its new APIs.
>
> If your extension is compatible with AOO 4.0, please take a moment to
> update the extension's compatibility information so that end-users will
> know it works with the latest release. If your extension is not compatible

Is it clear how to do this?  Is there any doc we should point them to for this?

> we'd encourage you to release a new version if you have time, or ask people
> to help you with that at the API mailing-list (http://openoffice.apache
> .org/mailing-lists.html#api-mailing-list-public).
>
> How do you like this?
>

Good.

-Rob

> Roberto
>
>
>
>>
>> Roberto
>>
>>
>>
>>>
>>> -Rob
>>>
>>>
>>> > Roberto
>>> >
>>> >
>>> >>
>>> >> 3) We announce the 4.0 API changes on the API list and answered any
>>> >> questions that came up.
>>> >>
>>> >> True, not everyone is happy about the changes.  But we tried to ensure
>>> >> that every active extension author was aware of the changes coming.
>>> >>
>>> >> Regards,
>>> >>
>>> >> -Rob
>>> >>
>>> >> > Hagar
>>> >> >
>>> >> > -
>>> >> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> >> >
>>> >> > For additional commands, e-mail: dev-h...@openoffice.apache.org
>>> >> >
>>> >>
>>> >> -
>>> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>> >>
>>> >>
>>>
>>> 

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Roberto Galoppini]

2013/7/29 Roberto Galoppini 

>
>
>
> 2013/7/27 Rob Weir 
>
>> On Sat, Jul 27, 2013 at 4:59 PM, Roberto Galoppini
>>  wrote:
>> > 2013/7/27 Rob Weir 
>> >
>> >> On Fri, Jul 26, 2013 at 5:59 PM, Hagar Delest <
>> hagar.del...@laposte.net>
>> >> wrote:
>> >> > Le 26/07/2013 15:40, Roberto Galoppini a écrit :
>> >> >
>> >> >> A) a link to a version compatible with AOO 4.0 has been added for
>> >> >> http://extensions.openoffice.org/en/project/pdfimport and
>> >> >> http://extensions.openoffice.org/en/project/mysql_connector
>> >> >>
>> >> >> B) 4.0" has been added to the list of possible compatibilities. For
>> >> >> example
>> >> >> http://extensions.openoffice.org/en/node/287/releases doesn't
>> enlist
>> >> 4.0
>> >> >> among AOO compatible versions, while new extensions have that set,
>> see
>> >> for
>> >> >> example http://extensions.openoffice.org/en/node/5644/releases.
>> >> >>
>> >> >> Note that it's up to the author to indicate his/her extension
>> >> >> compatibility
>> >> >> list, and he/she can update it without the need to upload the file
>> >> again.
>> >> >
>> >> >
>> >> > But it means that the author has to be aware that there is a change
>> and
>> >> he
>> >> > has to update the relevant field.
>> >> > There is no script that could add the lack of compatibility if the
>> >> extension
>> >> > has not been updated yet?
>> >>
>> >
>> > The lack of compatibility is somehow implicit if you read that a given
>> > extension is compatible with OpenOffice 3.3 or AOO 3.4 and it doesn't
>> > mention AOO 4.0. See below about how to make sure such info is
>> up-to-date.
>> >
>> >
>> >
>> >> >
>> >> > For the record, in the case of the Lorem ipsum extension, the author
>> >> doesn't
>> >> > seem to be willing to update it...
>> >> >
>> >>
>> >> If an extension is essentially abandoned then it is only a matter of
>> >> time before it breaks.  Either that or we put ourselves into a
>> >> position where we can never evolve and improve our API.  We should
>> >> focus on the needs of active extension developers, not the inactive
>> >> ones.
>> >>
>> >> This is what we did to keep extension authors in the loop:
>> >>
>> >> 1) We created a special mailing list, a...@openoffice.apache.org for
>> >> discussions about extensions.
>> >>
>> >> 2) We worked with SourceForge to send an email to all registered
>> >> extension authors to invite them to the new list.  This was done
>> >> before the *.openoffice.org email forwarder was shut down, so they all
>> >> should have received the note.
>> >>
>> >
>> > We might resend an email to all Extensions' authors re-inviting them to
>> > subscribe to the API mailing-list and also inviting them to check if
>> their
>> > extensions do work with AOO 4.0 and eventually update their extension
>> page
>> > accordingly.
>> >
>> > Does it sound like a plan?
>> >
>>
>> Reminders are good.
>>
>
> So what do we want to tell them, does anyone want to craft a draft message
> for AOOE authors?
>


Subject: About Apache OpenOffice New Release and Updating your Extension's
Compatibility Info

Dear OpenOffice.org Extensions author,

As you may have heard, Apache OpenOffice 4.0 is now out, and we'd like to
invite you to test your own extension and figure out if it is or is not
compatible with Apache OpenOffice 4.0 and its new APIs.

If your extension is compatible with AOO 4.0, please take a moment to
update the extension's compatibility information so that end-users will
know it works with the latest release. If your extension is not compatible
we'd encourage you to release a new version if you have time, or ask people
to help you with that at the API mailing-list (http://openoffice.apache
.org/mailing-lists.html#api-mailing-list-public).

How do you like this?

Roberto



>
> Roberto
>
>
>
>>
>> -Rob
>>
>>
>> > Roberto
>> >
>> >
>> >>
>> >> 3) We announce the 4.0 API changes on the API list and answered any
>> >> questions that came up.
>> >>
>> >> True, not everyone is happy about the changes.  But we tried to ensure
>> >> that every active extension author was aware of the changes coming.
>> >>
>> >> Regards,
>> >>
>> >> -Rob
>> >>
>> >> > Hagar
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> >> >
>> >> > For additional commands, e-mail: dev-h...@openoffice.apache.org
>> >> >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> >>
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
>

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Roberto Galoppini]

2013/7/27 Rob Weir 

> On Sat, Jul 27, 2013 at 4:59 PM, Roberto Galoppini
>  wrote:
> > 2013/7/27 Rob Weir 
> >
> >> On Fri, Jul 26, 2013 at 5:59 PM, Hagar Delest  >
> >> wrote:
> >> > Le 26/07/2013 15:40, Roberto Galoppini a écrit :
> >> >
> >> >> A) a link to a version compatible with AOO 4.0 has been added for
> >> >> http://extensions.openoffice.org/en/project/pdfimport and
> >> >> http://extensions.openoffice.org/en/project/mysql_connector
> >> >>
> >> >> B) 4.0" has been added to the list of possible compatibilities. For
> >> >> example
> >> >> http://extensions.openoffice.org/en/node/287/releases doesn't enlist
> >> 4.0
> >> >> among AOO compatible versions, while new extensions have that set,
> see
> >> for
> >> >> example http://extensions.openoffice.org/en/node/5644/releases.
> >> >>
> >> >> Note that it's up to the author to indicate his/her extension
> >> >> compatibility
> >> >> list, and he/she can update it without the need to upload the file
> >> again.
> >> >
> >> >
> >> > But it means that the author has to be aware that there is a change
> and
> >> he
> >> > has to update the relevant field.
> >> > There is no script that could add the lack of compatibility if the
> >> extension
> >> > has not been updated yet?
> >>
> >
> > The lack of compatibility is somehow implicit if you read that a given
> > extension is compatible with OpenOffice 3.3 or AOO 3.4 and it doesn't
> > mention AOO 4.0. See below about how to make sure such info is
> up-to-date.
> >
> >
> >
> >> >
> >> > For the record, in the case of the Lorem ipsum extension, the author
> >> doesn't
> >> > seem to be willing to update it...
> >> >
> >>
> >> If an extension is essentially abandoned then it is only a matter of
> >> time before it breaks.  Either that or we put ourselves into a
> >> position where we can never evolve and improve our API.  We should
> >> focus on the needs of active extension developers, not the inactive
> >> ones.
> >>
> >> This is what we did to keep extension authors in the loop:
> >>
> >> 1) We created a special mailing list, a...@openoffice.apache.org for
> >> discussions about extensions.
> >>
> >> 2) We worked with SourceForge to send an email to all registered
> >> extension authors to invite them to the new list.  This was done
> >> before the *.openoffice.org email forwarder was shut down, so they all
> >> should have received the note.
> >>
> >
> > We might resend an email to all Extensions' authors re-inviting them to
> > subscribe to the API mailing-list and also inviting them to check if
> their
> > extensions do work with AOO 4.0 and eventually update their extension
> page
> > accordingly.
> >
> > Does it sound like a plan?
> >
>
> Reminders are good.
>

So what do we want to tell them, does anyone want to craft a draft message
for AOOE authors?

Roberto



>
> -Rob
>
>
> > Roberto
> >
> >
> >>
> >> 3) We announce the 4.0 API changes on the API list and answered any
> >> questions that came up.
> >>
> >> True, not everyone is happy about the changes.  But we tried to ensure
> >> that every active extension author was aware of the changes coming.
> >>
> >> Regards,
> >>
> >> -Rob
> >>
> >> > Hagar
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> >
> >> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Sat, Jul 27, 2013 at 4:59 PM, Roberto Galoppini
 wrote:
> 2013/7/27 Rob Weir 
>
>> On Fri, Jul 26, 2013 at 5:59 PM, Hagar Delest 
>> wrote:
>> > Le 26/07/2013 15:40, Roberto Galoppini a écrit :
>> >
>> >> A) a link to a version compatible with AOO 4.0 has been added for
>> >> http://extensions.openoffice.org/en/project/pdfimport and
>> >> http://extensions.openoffice.org/en/project/mysql_connector
>> >>
>> >> B) 4.0" has been added to the list of possible compatibilities. For
>> >> example
>> >> http://extensions.openoffice.org/en/node/287/releases doesn't enlist
>> 4.0
>> >> among AOO compatible versions, while new extensions have that set, see
>> for
>> >> example http://extensions.openoffice.org/en/node/5644/releases.
>> >>
>> >> Note that it's up to the author to indicate his/her extension
>> >> compatibility
>> >> list, and he/she can update it without the need to upload the file
>> again.
>> >
>> >
>> > But it means that the author has to be aware that there is a change and
>> he
>> > has to update the relevant field.
>> > There is no script that could add the lack of compatibility if the
>> extension
>> > has not been updated yet?
>>
>
> The lack of compatibility is somehow implicit if you read that a given
> extension is compatible with OpenOffice 3.3 or AOO 3.4 and it doesn't
> mention AOO 4.0. See below about how to make sure such info is up-to-date.
>
>
>
>> >
>> > For the record, in the case of the Lorem ipsum extension, the author
>> doesn't
>> > seem to be willing to update it...
>> >
>>
>> If an extension is essentially abandoned then it is only a matter of
>> time before it breaks.  Either that or we put ourselves into a
>> position where we can never evolve and improve our API.  We should
>> focus on the needs of active extension developers, not the inactive
>> ones.
>>
>> This is what we did to keep extension authors in the loop:
>>
>> 1) We created a special mailing list, a...@openoffice.apache.org for
>> discussions about extensions.
>>
>> 2) We worked with SourceForge to send an email to all registered
>> extension authors to invite them to the new list.  This was done
>> before the *.openoffice.org email forwarder was shut down, so they all
>> should have received the note.
>>
>
> We might resend an email to all Extensions' authors re-inviting them to
> subscribe to the API mailing-list and also inviting them to check if their
> extensions do work with AOO 4.0 and eventually update their extension page
> accordingly.
>
> Does it sound like a plan?
>

Reminders are good.

-Rob


> Roberto
>
>
>>
>> 3) We announce the 4.0 API changes on the API list and answered any
>> questions that came up.
>>
>> True, not everyone is happy about the changes.  But we tried to ensure
>> that every active extension author was aware of the changes coming.
>>
>> Regards,
>>
>> -Rob
>>
>> > Hagar
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> >
>> > For additional commands, e-mail: dev-h...@openoffice.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Roberto Galoppini]

2013/7/27 Rob Weir 

> On Fri, Jul 26, 2013 at 5:59 PM, Hagar Delest 
> wrote:
> > Le 26/07/2013 15:40, Roberto Galoppini a écrit :
> >
> >> A) a link to a version compatible with AOO 4.0 has been added for
> >> http://extensions.openoffice.org/en/project/pdfimport and
> >> http://extensions.openoffice.org/en/project/mysql_connector
> >>
> >> B) 4.0" has been added to the list of possible compatibilities. For
> >> example
> >> http://extensions.openoffice.org/en/node/287/releases doesn't enlist
> 4.0
> >> among AOO compatible versions, while new extensions have that set, see
> for
> >> example http://extensions.openoffice.org/en/node/5644/releases.
> >>
> >> Note that it's up to the author to indicate his/her extension
> >> compatibility
> >> list, and he/she can update it without the need to upload the file
> again.
> >
> >
> > But it means that the author has to be aware that there is a change and
> he
> > has to update the relevant field.
> > There is no script that could add the lack of compatibility if the
> extension
> > has not been updated yet?
>

The lack of compatibility is somehow implicit if you read that a given
extension is compatible with OpenOffice 3.3 or AOO 3.4 and it doesn't
mention AOO 4.0. See below about how to make sure such info is up-to-date.



> >
> > For the record, in the case of the Lorem ipsum extension, the author
> doesn't
> > seem to be willing to update it...
> >
>
> If an extension is essentially abandoned then it is only a matter of
> time before it breaks.  Either that or we put ourselves into a
> position where we can never evolve and improve our API.  We should
> focus on the needs of active extension developers, not the inactive
> ones.
>
> This is what we did to keep extension authors in the loop:
>
> 1) We created a special mailing list, a...@openoffice.apache.org for
> discussions about extensions.
>
> 2) We worked with SourceForge to send an email to all registered
> extension authors to invite them to the new list.  This was done
> before the *.openoffice.org email forwarder was shut down, so they all
> should have received the note.
>

We might resend an email to all Extensions' authors re-inviting them to
subscribe to the API mailing-list and also inviting them to check if their
extensions do work with AOO 4.0 and eventually update their extension page
accordingly.

Does it sound like a plan?

Roberto


>
> 3) We announce the 4.0 API changes on the API list and answered any
> questions that came up.
>
> True, not everyone is happy about the changes.  But we tried to ensure
> that every active extension author was aware of the changes coming.
>
> Regards,
>
> -Rob
>
> > Hagar
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Andrea Pescetti]

On 26/07/2013 Hagar Delest wrote:

Here we are. The first messages (ML and forum) about incompatibility are
coming.


I'm keeping
http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0
up-to-date with what is reported on this list. Feel free to collect 
further information there.



A quick tutorial on how to update the extension in case authors want to
make the change urgently?


I don't have one, but it would belong to that page to. There's only a 
TODO so far (and I don't know the exact details, otherwise I would have 
written it).


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Fri, Jul 26, 2013 at 5:59 PM, Hagar Delest  wrote:
> Le 26/07/2013 15:40, Roberto Galoppini a écrit :
>
>> A) a link to a version compatible with AOO 4.0 has been added for
>> http://extensions.openoffice.org/en/project/pdfimport and
>> http://extensions.openoffice.org/en/project/mysql_connector
>>
>> B) 4.0" has been added to the list of possible compatibilities. For
>> example
>> http://extensions.openoffice.org/en/node/287/releases doesn't enlist 4.0
>> among AOO compatible versions, while new extensions have that set, see for
>> example http://extensions.openoffice.org/en/node/5644/releases.
>>
>> Note that it's up to the author to indicate his/her extension
>> compatibility
>> list, and he/she can update it without the need to upload the file again.
>
>
> But it means that the author has to be aware that there is a change and he
> has to update the relevant field.
> There is no script that could add the lack of compatibility if the extension
> has not been updated yet?
>
> For the record, in the case of the Lorem ipsum extension, the author doesn't
> seem to be willing to update it...
>

If an extension is essentially abandoned then it is only a matter of
time before it breaks.  Either that or we put ourselves into a
position where we can never evolve and improve our API.  We should
focus on the needs of active extension developers, not the inactive
ones.

This is what we did to keep extension authors in the loop:

1) We created a special mailing list, a...@openoffice.apache.org for
discussions about extensions.

2) We worked with SourceForge to send an email to all registered
extension authors to invite them to the new list.  This was done
before the *.openoffice.org email forwarder was shut down, so they all
should have received the note.

3) We announce the 4.0 API changes on the API list and answered any
questions that came up.

True, not everyone is happy about the changes.  But we tried to ensure
that every active extension author was aware of the changes coming.

Regards,

-Rob

> Hagar
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Hagar Delest]

Le 26/07/2013 15:40, Roberto Galoppini a écrit :

A) a link to a version compatible with AOO 4.0 has been added for
http://extensions.openoffice.org/en/project/pdfimport and
http://extensions.openoffice.org/en/project/mysql_connector

B) 4.0" has been added to the list of possible compatibilities. For example
http://extensions.openoffice.org/en/node/287/releases doesn't enlist 4.0
among AOO compatible versions, while new extensions have that set, see for
example http://extensions.openoffice.org/en/node/5644/releases.

Note that it's up to the author to indicate his/her extension compatibility
list, and he/she can update it without the need to upload the file again.


But it means that the author has to be aware that there is a change and he has 
to update the relevant field.
There is no script that could add the lack of compatibility if the extension 
has not been updated yet?

For the record, in the case of the Lorem ipsum extension, the author doesn't 
seem to be willing to update it...

Hagar

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Roberto Galoppini]

2013/7/26 Hagar Delest 

> Top posting.
>
> Here we are. The first messages (ML and forum) about incompatibility are
> coming.
> The identified extensions (with toolbar and not updated for 4.0) should be
> at least tagged in the extension site as not compatible with 4.0.
>

 This has been already done actually. To be more specific:

A) a link to a version compatible with AOO 4.0 has been added for
http://extensions.openoffice.org/en/project/pdfimport and
http://extensions.openoffice.org/en/project/mysql_connector

B) 4.0" has been added to the list of possible compatibilities. For example
http://extensions.openoffice.org/en/node/287/releases doesn't enlist 4.0
among AOO compatible versions, while new extensions have that set, see for
example http://extensions.openoffice.org/en/node/5644/releases.

Note that it's up to the author to indicate his/her extension compatibility
list, and he/she can update it without the need to upload the file again.

Roberto


>
> A quick tutorial on how to update the extension in case authors want to
> make the change urgently?
>
> Hagar
>
>
> Le 13/02/2013 00:00, Rob Weir a écrit :
>
>  On Tue, Feb 12, 2013 at 5:31 PM, Hagar Delest 
>> wrote:
>>
>>> Le 12/02/2013 13:05, Rob Weir a écrit :
>>>
>>>  I don't know.  I was asking a question.  But I think this is an
 important question:  Why would an extension author not update their
 extension for AOO 4.0?  Some hypothetical answers:

 1) The extension is unmaintained

>>>
>>>
>>> One of the top reasons I guess. I myslef made extensions for my own use.
>>> I
>>> would have to tweak it. Since I've done them some time ago, I would have
>>> to
>>> dive again in specifications to make the changes.
>>>
>>>
>>>
>>>  2)  The author cannot be located or we have no way to notify them of
 changes

>>>
>>>
>>> May be related to 1).
>>>
>>>
>>>
>>>  3) It is not clear to the author what technical changes are needed

>>>
>>>
>>> Was a communication plan issued to warn the authors about that?
>>> Don't tell me the release notes are for that. Almost nobody read the
>>> release
>>> notes (at least until the end).
>>> I guess that many extensions mlaintainers don't follow this dev list at
>>> all.
>>>
>>>
>> No, no.  The Release Notes are just what I proposed to collect these
>> kinds of items.  If we actually make breaking changes I'd expect to
>> see a bigger attempt to reach out to extension authors:
>>
>> 1) blog post
>>
>> 2) post to API list and forum
>>
>> 3) maybe banner on the extensions website itself
>>
>> But this would make more sense after the changes are made and when we
>> can point to complete instructions as well as developer snaphot build
>> that the author can use to test their modifications.
>>
>> What is not clear is how much notice is needed.  1 month?  2 months?
>>  More?
>>
>> -Rob
>>
>>
>>
>>>
>>>  4) There is not sufficient calendar time for the extension author to
 make the needed changes before we release, or the work required is too
 much for the author to fit into his schedule

>>>
>>>
>>> May be related to 3). Without any warning, few chances to implement any
>>> change.
>>>
>>>
>>>
>>>  5) The author attempts changes but they don't work or they introduce
 new problems

>>>
>>>
>>> Rather unlikely.
>>>
>>>
>>>
>>>  6) The results of not making the changes is not clear, so the author
 mistakenly thinks they are optional changes

>>>
>>>
>>> Or he just don't care anymore about the extension. So it needs to be
>>> taken
>>> over by someone else. But how we could know that?
>>>
>>>
>>>
>>>  7) Author has technical or account issues with the extensions website
 and is unable to upload a new version, and does not know where to get
 help.

 These are all possible concerns, but I think most of them can be
 managed with good communications and advance notice.

 There is also the possibility of:

 8) Inconvenience -- it is natural for anyone to complain about needing
 to do additional work where they don't see the advantage.  So it is
 natural that we will expect complaints, followed in the end by
 conformance with the required changes.

>>>
>>>
>>> Yes but what about the loss of confidence from users who will be first
>>> frustrated by an upgrade that breaks more things than fix them? Then they
>>> will have to do some homework to find out what the problem is (again,
>>> don't
>>> tell me about release notes). And wait in the end for someone to fix it.
>>> What if they do need their extensions meanwhile?
>>>
>>> One side aspect: what about extension update warning? If a new version is
>>> detected but the user doesn't upgrade to 4.0, are we sure that the
>>> minimal
>>> version will be checked first, before the new extension is installed by
>>> the
>>> user? Has he to download it before being warned that it's in fact not
>>> compatible with his current AOO/OOo version?
>>>
>>> I'm not against the change. I'm for a 

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Hagar Delest]

Top posting.

Here we are. The first messages (ML and forum) about incompatibility are coming.
The identified extensions (with toolbar and not updated for 4.0) should be at 
least tagged in the extension site as not compatible with 4.0.

A quick tutorial on how to update the extension in case authors want to make 
the change urgently?

Hagar


Le 13/02/2013 00:00, Rob Weir a écrit :


On Tue, Feb 12, 2013 at 5:31 PM, Hagar Delest  wrote:

Le 12/02/2013 13:05, Rob Weir a écrit :


I don't know.  I was asking a question.  But I think this is an
important question:  Why would an extension author not update their
extension for AOO 4.0?  Some hypothetical answers:

1) The extension is unmaintained



One of the top reasons I guess. I myslef made extensions for my own use. I
would have to tweak it. Since I've done them some time ago, I would have to
dive again in specifications to make the changes.




2)  The author cannot be located or we have no way to notify them of
changes



May be related to 1).




3) It is not clear to the author what technical changes are needed



Was a communication plan issued to warn the authors about that?
Don't tell me the release notes are for that. Almost nobody read the release
notes (at least until the end).
I guess that many extensions mlaintainers don't follow this dev list at all.



No, no.  The Release Notes are just what I proposed to collect these
kinds of items.  If we actually make breaking changes I'd expect to
see a bigger attempt to reach out to extension authors:

1) blog post

2) post to API list and forum

3) maybe banner on the extensions website itself

But this would make more sense after the changes are made and when we
can point to complete instructions as well as developer snaphot build
that the author can use to test their modifications.

What is not clear is how much notice is needed.  1 month?  2 months?  More?

-Rob






4) There is not sufficient calendar time for the extension author to
make the needed changes before we release, or the work required is too
much for the author to fit into his schedule



May be related to 3). Without any warning, few chances to implement any
change.




5) The author attempts changes but they don't work or they introduce
new problems



Rather unlikely.




6) The results of not making the changes is not clear, so the author
mistakenly thinks they are optional changes



Or he just don't care anymore about the extension. So it needs to be taken
over by someone else. But how we could know that?




7) Author has technical or account issues with the extensions website
and is unable to upload a new version, and does not know where to get
help.

These are all possible concerns, but I think most of them can be
managed with good communications and advance notice.

There is also the possibility of:

8) Inconvenience -- it is natural for anyone to complain about needing
to do additional work where they don't see the advantage.  So it is
natural that we will expect complaints, followed in the end by
conformance with the required changes.



Yes but what about the loss of confidence from users who will be first
frustrated by an upgrade that breaks more things than fix them? Then they
will have to do some homework to find out what the problem is (again, don't
tell me about release notes). And wait in the end for someone to fix it.
What if they do need their extensions meanwhile?

One side aspect: what about extension update warning? If a new version is
detected but the user doesn't upgrade to 4.0, are we sure that the minimal
version will be checked first, before the new extension is installed by the
user? Has he to download it before being warned that it's in fact not
compatible with his current AOO/OOo version?

I'm not against the change. I'm for a controlled one, that has no impact on
end-users. So the main points are: communication to the extensions
maintainers (what about the extensions hosted on their personal pages and
not on sourceforge?), preparation of the updates and transition period.

Hagar


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Roberto Galoppini]

On Thu, Mar 7, 2013 at 1:36 PM, Herbert Dürr  wrote:
> On 2013/03/07 11:41 AM, Roberto Galoppini wrote:
>>
>> Below the list of Extensions top downloads during the last month:
>>
>> #1 http://extensions.services.openoffice.org/node/3620 Monthly: 1725
>> [...]
>>
>> #50 http://extensions.services.openoffice.org/node/3409 Monthly: 42
>
>
> The extension popularity list is very interesting. Thanks Roberto!

Keep in mind those are the most popular among Extensions containing
Addons.xcu with OfficeToolBar. The most popular in absolute terms are
found at http://extensions.services.openoffice.org/en/most_popular/month

> For easier consumption I annotated the list with the extension names:
>
> #1 http://extensions.services.openoffice.org/node/3620 Monthly: 1725
> (WriterRotationTool)
> #2 http://extensions.services.openoffice.org/node/137 Monthly: 1583
> (OOo2GoogleDocs)
> #3 http://extensions.services.openoffice.org/node/4303 Monthly: 1307
> (Diagram)
> #4 http://extensions.services.openoffice.org/node/496 Monthly: 1221  (Oracle
> Presentation Minimizer)
> #5 http://extensions.services.openoffice.org/node/415 Monthly: 649
> (CropOOo)
> #6 http://extensions.services.openoffice.org/node/4016 Monthly: 645
> (Typography toolbar)
> #7 http://extensions.services.openoffice.org/node/567 Monthly: 424
> (Convert Text To Number (and date))
> #8 http://extensions.services.openoffice.org/node/2659 Monthly: 399
> (Readability Report)
> #9 http://extensions.services.openoffice.org/node/1719 Monthly: 368
> (MultiSave)
> #10 http://extensions.services.openoffice.org/node/5510 Monthly: 330
> (PixCompress)
> #11 http://extensions.services.openoffice.org/node/383 Monthly: 328
> (Template Changer)
> #12 http://extensions.services.openoffice.org/node/2649 Monthly: 311 (Read
> Text)
> #13 http://extensions.services.openoffice.org/node/2355 Monthly: 224 (CLC09
> quick_formule)
> #14 http://extensions.services.openoffice.org/node/3023 Monthly: 218 (RGB)
> #15 http://extensions.services.openoffice.org/node/5305 Monthly: 203 (SmART
> Extension en Español)
> #16 http://extensions.services.openoffice.org/node/26 Monthly: 189   (Sun
> Weblog Publisher)
> #17 http://extensions.services.openoffice.org/node/1210 Monthly: 173 (GeOOo
> : Create Thematic maps with Ooo)
> #18 http://extensions.services.openoffice.org/node/3286 Monthly: 167 (Change
> Picture)
> #19 http://extensions.services.openoffice.org/node/545 Monthly: 163
> (eVoice)
> #20 http://extensions.services.openoffice.org/node/4710 Monthly: 156
> (PixelPluz Image Editor for Writer)
> #21 http://extensions.services.openoffice.org/node/3902 Monthly: 153 (EPUB
> Generator)
> #22 http://extensions.services.openoffice.org/node/5595 Monthly: 152 (Basic
> IDE Tools)
> #23 http://extensions.services.openoffice.org/node/4849 Monthly: 145 (Paste
> From Web)
> #24 http://extensions.services.openoffice.org/node/2771 Monthly: 135
> (Chiffres en lettres)
> #25 http://extensions.services.openoffice.org/node/4410 Monthly: 135 (Export
> As Doc)
> #26 http://extensions.services.openoffice.org/node/5151 Monthly: 133 (OCR
> helper)
> #27 http://extensions.services.openoffice.org/node/2169 Monthly: 131
> (Thousands Separator)
> #28 http://extensions.services.openoffice.org/node/283 Monthly: 130
> (MultiDiff)
> #29 http://extensions.services.openoffice.org/node/3661 Monthly: 122
> (TradutorOOoNote)
> #30 http://extensions.services.openoffice.org/node/3700 Monthly: 119
> (Versatile Calculator for Open office)
> #31 http://extensions.services.openoffice.org/node/4213 Monthly: 117 (Copy
> only visible cells)
> #32 http://extensions.services.openoffice.org/node/4658 Monthly: 117 (Solvit
> (Advanced Solver of System of Equations - Linear/Nonlinear))
> #33 http://extensions.services.openoffice.org/node/2201 Monthly: 111
> (OOoFormulaEditor)
> #34 http://extensions.services.openoffice.org/node/1798 Monthly: 89
> (CalcEasyToolbar)
> #35 http://extensions.services.openoffice.org/node/5392 Monthly: 88  (IBM
> Connections Connector for Apache OpenOffice)
> #36 http://extensions.services.openoffice.org/node/5317 Monthly: 87  (MMove)
> #37 http://extensions.services.openoffice.org/node/847 Monthly: 83
> (OOoTranslit)
> #38 http://extensions.services.openoffice.org/node/1039 Monthly: 80
> (Color2Rows)
> #39 http://extensions.services.openoffice.org/node/207 Monthly: 76
> (BorderLiner)
> #40 http://extensions.services.openoffice.org/node/4739 Monthly: 65
> (Mini-Calculator)
> #41 http://extensions.services.openoffice.org/node/640 Monthly: 64
> (ImpressTextResizer)
> #42 http://extensions.services.openoffice.org/node/1864 Monthly: 61
> (OOoLilyPond)
> #43 http://extensions.services.openoffice.org/node/3909 Monthly: 60 (eLAIX)
> #44 http://extensions.services.openoffice.org/node/4150 Monthly: 54 (Photo
> Album ES)
> #45 http://extensions.services.openoffice.org/node/4798 Monthly: 54
> (CleanDoc)
> #46 http://extensions.services.openoffice.org/node/2085 Monthly: 50 (WiRWiB
> - Wordnet Based suggestive writing aid  for creat

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Herbert Dürr]

On 2013/03/07 11:41 AM, Roberto Galoppini wrote:

Below the list of Extensions top downloads during the last month:

#1 http://extensions.services.openoffice.org/node/3620 Monthly: 1725
[...]
#50 http://extensions.services.openoffice.org/node/3409 Monthly: 42


The extension popularity list is very interesting. Thanks Roberto!

For easier consumption I annotated the list with the extension names:

#1 http://extensions.services.openoffice.org/node/3620 Monthly: 1725 
(WriterRotationTool)
#2 http://extensions.services.openoffice.org/node/137 Monthly: 1583  
(OOo2GoogleDocs)
#3 http://extensions.services.openoffice.org/node/4303 Monthly: 1307 (Diagram)
#4 http://extensions.services.openoffice.org/node/496 Monthly: 1221  (Oracle 
Presentation Minimizer)
#5 http://extensions.services.openoffice.org/node/415 Monthly: 649   (CropOOo)
#6 http://extensions.services.openoffice.org/node/4016 Monthly: 645  
(Typography toolbar)
#7 http://extensions.services.openoffice.org/node/567 Monthly: 424   (Convert 
Text To Number (and date))
#8 http://extensions.services.openoffice.org/node/2659 Monthly: 399  
(Readability Report)
#9 http://extensions.services.openoffice.org/node/1719 Monthly: 368  (MultiSave)
#10 http://extensions.services.openoffice.org/node/5510 Monthly: 330 
(PixCompress)
#11 http://extensions.services.openoffice.org/node/383 Monthly: 328  (Template 
Changer)
#12 http://extensions.services.openoffice.org/node/2649 Monthly: 311 (Read Text)
#13 http://extensions.services.openoffice.org/node/2355 Monthly: 224 (CLC09 
quick_formule)
#14 http://extensions.services.openoffice.org/node/3023 Monthly: 218 (RGB)
#15 http://extensions.services.openoffice.org/node/5305 Monthly: 203 (SmART 
Extension en Español)
#16 http://extensions.services.openoffice.org/node/26 Monthly: 189   (Sun 
Weblog Publisher)
#17 http://extensions.services.openoffice.org/node/1210 Monthly: 173 (GeOOo : 
Create Thematic maps with Ooo)
#18 http://extensions.services.openoffice.org/node/3286 Monthly: 167 (Change 
Picture)
#19 http://extensions.services.openoffice.org/node/545 Monthly: 163  (eVoice)
#20 http://extensions.services.openoffice.org/node/4710 Monthly: 156 (PixelPluz 
Image Editor for Writer)
#21 http://extensions.services.openoffice.org/node/3902 Monthly: 153 (EPUB 
Generator)
#22 http://extensions.services.openoffice.org/node/5595 Monthly: 152 (Basic IDE 
Tools)
#23 http://extensions.services.openoffice.org/node/4849 Monthly: 145 (Paste 
From Web)
#24 http://extensions.services.openoffice.org/node/2771 Monthly: 135 (Chiffres 
en lettres)
#25 http://extensions.services.openoffice.org/node/4410 Monthly: 135 (Export As 
Doc)
#26 http://extensions.services.openoffice.org/node/5151 Monthly: 133 (OCR 
helper)
#27 http://extensions.services.openoffice.org/node/2169 Monthly: 131 (Thousands 
Separator)
#28 http://extensions.services.openoffice.org/node/283 Monthly: 130  (MultiDiff)
#29 http://extensions.services.openoffice.org/node/3661 Monthly: 122 
(TradutorOOoNote)
#30 http://extensions.services.openoffice.org/node/3700 Monthly: 119 (Versatile 
Calculator for Open office)
#31 http://extensions.services.openoffice.org/node/4213 Monthly: 117 (Copy only 
visible cells)
#32 http://extensions.services.openoffice.org/node/4658 Monthly: 117 (Solvit (Advanced Solver of System of Equations - 
Linear/Nonlinear))

#33 http://extensions.services.openoffice.org/node/2201 Monthly: 111 
(OOoFormulaEditor)
#34 http://extensions.services.openoffice.org/node/1798 Monthly: 89  
(CalcEasyToolbar)
#35 http://extensions.services.openoffice.org/node/5392 Monthly: 88  (IBM 
Connections Connector for Apache OpenOffice)
#36 http://extensions.services.openoffice.org/node/5317 Monthly: 87  (MMove)
#37 http://extensions.services.openoffice.org/node/847 Monthly: 83  
(OOoTranslit)
#38 http://extensions.services.openoffice.org/node/1039 Monthly: 80 (Color2Rows)
#39 http://extensions.services.openoffice.org/node/207 Monthly: 76  
(BorderLiner)
#40 http://extensions.services.openoffice.org/node/4739 Monthly: 65 
(Mini-Calculator)
#41 http://extensions.services.openoffice.org/node/640 Monthly: 64  
(ImpressTextResizer)
#42 http://extensions.services.openoffice.org/node/1864 Monthly: 61 
(OOoLilyPond)
#43 http://extensions.services.openoffice.org/node/3909 Monthly: 60 (eLAIX)
#44 http://extensions.services.openoffice.org/node/4150 Monthly: 54 (Photo 
Album ES)
#45 http://extensions.services.openoffice.org/node/4798 Monthly: 54 (CleanDoc)
#46 http://extensions.services.openoffice.org/node/2085 Monthly: 50 (WiRWiB - Wordnet Based suggestive writing aid  for creative 
writing in English and Hindi)

#47 http://extensions.services.openoffice.org/node/603 Monthly: 49  (odt2pml - 
Writer to eReader Export Extension)
#48 http://extensions.services.openoffice.org/node/4979 Monthly: 48 
(Bibliography Manager)
#49 http://extensions.services.openoffice.org/node/4361 Monthly: 45 (OpenKM Add 
On)
#50 http://extensions.services.openoffice.org/node/3409 Monthly: 42 
(MatrixManipulator)

H

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Roberto Galoppini]

On Mon, Feb 25, 2013 at 4:49 PM, Jürgen Schmidt  wrote:
> On 2/25/13 4:36 PM, Roberto Galoppini wrote:
>> On Thu, Feb 21, 2013 at 2:28 PM, Jürgen Schmidt  
>> wrote:
>>> On 2/21/13 10:05 AM, Ariel Constenla-Haile wrote:
 On Thu, Feb 21, 2013 at 09:22:34AM +0100, Jürgen Schmidt wrote:
>>> The first step should be a simple check if an Addons.xcu is
>>> contained at all. Something like "unzip -l  | grep
>>> Addons.xcu" should be enough. The second step if an
>>> Addons.xcu is contained is to check for the ">> oor:name="OfficeToolBar">" entry. Only if this entry exists
>>> the Addons.xcu the extension has to be updated.

 This might be error prone, because the file can have any name, all
 it matters is the media type in the META-INF manifest and the OO
 registry package and name in the file itself.

 While it's highly rare to find a lala.lala, I've found an
 "addons.xcu" (in lowercase). No wonder there is no OfficeToolBar in
 this particular extension, but the extension does not work in AOO
 4.0 due to API changes (what shows that the whole discussion
 centered on the schema change is full of ungrounded assumptions,
 and lack of knowledge on the subject).
>>>
>>> ignore case is probably a good idea, a complete different name is
>>> probably rather seldom. But from a technical point of view you are
>>> correct.
>>>
>>> We don't need exact data but it would be nice to get an impression how
>>> often it is used.
>
> it would definitely help to get an overview about which extension we are
> talking. Based on this info we could contact the owners and can inform
> them about the change.

Below the list of Extensions top downloads during the last month:

#1 http://extensions.services.openoffice.org/node/3620 Monthly: 1725
#2 http://extensions.services.openoffice.org/node/137 Monthly: 1583
#3 http://extensions.services.openoffice.org/node/4303 Monthly: 1307
#4 http://extensions.services.openoffice.org/node/496 Monthly: 1221
#5 http://extensions.services.openoffice.org/node/415 Monthly: 649
#6 http://extensions.services.openoffice.org/node/4016 Monthly: 645
#7 http://extensions.services.openoffice.org/node/567 Monthly: 424
#8 http://extensions.services.openoffice.org/node/2659 Monthly: 399
#9 http://extensions.services.openoffice.org/node/1719 Monthly: 368
#10 http://extensions.services.openoffice.org/node/5510 Monthly: 330
#11 http://extensions.services.openoffice.org/node/383 Monthly: 328
#12 http://extensions.services.openoffice.org/node/2649 Monthly: 311
#13 http://extensions.services.openoffice.org/node/2355 Monthly: 224
#14 http://extensions.services.openoffice.org/node/3023 Monthly: 218
#15 http://extensions.services.openoffice.org/node/5305 Monthly: 203
#16 http://extensions.services.openoffice.org/node/26 Monthly: 189
#17 http://extensions.services.openoffice.org/node/1210 Monthly: 173
#18 http://extensions.services.openoffice.org/node/3286 Monthly: 167
#19 http://extensions.services.openoffice.org/node/545 Monthly: 163
#20 http://extensions.services.openoffice.org/node/4710 Monthly: 156
#21 http://extensions.services.openoffice.org/node/3902 Monthly: 153
#22 http://extensions.services.openoffice.org/node/5595 Monthly: 152
#23 http://extensions.services.openoffice.org/node/4849 Monthly: 145
#24 http://extensions.services.openoffice.org/node/2771 Monthly: 135
#25 http://extensions.services.openoffice.org/node/4410 Monthly: 135
#26 http://extensions.services.openoffice.org/node/5151 Monthly: 133
#27 http://extensions.services.openoffice.org/node/2169 Monthly: 131
#28 http://extensions.services.openoffice.org/node/283 Monthly: 130
#29 http://extensions.services.openoffice.org/node/3661 Monthly: 122
#30 http://extensions.services.openoffice.org/node/3700 Monthly: 119
#31 http://extensions.services.openoffice.org/node/4213 Monthly: 117
#32 http://extensions.services.openoffice.org/node/4658 Monthly: 117
#33 http://extensions.services.openoffice.org/node/2201 Monthly: 111
#34 http://extensions.services.openoffice.org/node/1798 Monthly: 89
#35 http://extensions.services.openoffice.org/node/5392 Monthly: 88
#36 http://extensions.services.openoffice.org/node/5317 Monthly: 87
#37 http://extensions.services.openoffice.org/node/847 Monthly: 83
#38 http://extensions.services.openoffice.org/node/1039 Monthly: 80
#39 http://extensions.services.openoffice.org/node/207 Monthly: 76
#40 http://extensions.services.openoffice.org/node/4739 Monthly: 65
#41 http://extensions.services.openoffice.org/node/640 Monthly: 64
#42 http://extensions.services.openoffice.org/node/1864 Monthly: 61
#43 http://extensions.services.openoffice.org/node/3909 Monthly: 60
#44 http://extensions.services.openoffice.org/node/4150 Monthly: 54
#45 http://extensions.services.openoffice.org/node/4798 Monthly: 54
#46 http://extensions.services.openoffice.org/node/2085 Monthly: 50
#47 http://extensions.services.openoffice.org/node/603 Monthly: 49
#48 http://extensions.services.openoffice.or

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/25/13 4:36 PM, Roberto Galoppini wrote:
> On Thu, Feb 21, 2013 at 2:28 PM, Jürgen Schmidt  wrote:
>> On 2/21/13 10:05 AM, Ariel Constenla-Haile wrote:
>>> On Thu, Feb 21, 2013 at 09:22:34AM +0100, Jürgen Schmidt wrote:
>> The first step should be a simple check if an Addons.xcu is
>> contained at all. Something like "unzip -l  | grep
>> Addons.xcu" should be enough. The second step if an
>> Addons.xcu is contained is to check for the "> oor:name="OfficeToolBar">" entry. Only if this entry exists
>> the Addons.xcu the extension has to be updated.
>>>
>>> This might be error prone, because the file can have any name, all
>>> it matters is the media type in the META-INF manifest and the OO
>>> registry package and name in the file itself.
>>>
>>> While it's highly rare to find a lala.lala, I've found an
>>> "addons.xcu" (in lowercase). No wonder there is no OfficeToolBar in
>>> this particular extension, but the extension does not work in AOO
>>> 4.0 due to API changes (what shows that the whole discussion
>>> centered on the schema change is full of ungrounded assumptions,
>>> and lack of knowledge on the subject).
>>
>> ignore case is probably a good idea, a complete different name is
>> probably rather seldom. But from a technical point of view you are
>> correct.
>>
>> We don't need exact data but it would be nice to get an impression how
>> often it is used.

it would definitely help to get an overview about which extension we are
talking. Based on this info we could contact the owners and can inform
them about the change.

Juergen


>>
>> Juergen
>>
>>>
>>>
> 242 extensions contain  addons.xcu stensioni (total: 1065
> releases), 430 estensions don't (total: 1660 releases). Do you
> want us to check how many contain OfficeToolBar?

 If you could run a short script to check it, it would be very
 useful for us to make a final decision.
> 
> Officetoolbar used within 137 extensions (553 releases).
> 

 Maybe you can also provide some numbers about their downloads.
 Only th extensions that contain an Addons.xcu with OfficeToolBar
> 
> That's not really trivial, but it would be easier to figure out how
> many among top 50 contain Addons.xcu with OfficeToolBar.
> 
> Would it make the trick? If not I'll work on how to compute those numbers.
> 
> Let me know,
> 
> Roberto
> 
> 
>>> It would also be interesting to know the last time the extension
>>> was updated; besides that expecting unmaintained extensions to work
>>> on a new major release might not be plausible, the extension is
>>> likely not be adapted to any change if it is unmaintained, no
>>> matter how popular it is (example: the most popular, Oracle PDF
>>> Import Extension, Downloads: Week: 12,706, unmaintained since Dec.
>>> 2010, seems to be broken - according to the first three comments).
>>>
>>>
>>> Regards
>>>
>>
> 

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Roberto Galoppini]

On Thu, Feb 21, 2013 at 2:28 PM, Jürgen Schmidt  wrote:
> On 2/21/13 10:05 AM, Ariel Constenla-Haile wrote:
>> On Thu, Feb 21, 2013 at 09:22:34AM +0100, Jürgen Schmidt wrote:
> The first step should be a simple check if an Addons.xcu is
> contained at all. Something like "unzip -l  | grep
> Addons.xcu" should be enough. The second step if an
> Addons.xcu is contained is to check for the " oor:name="OfficeToolBar">" entry. Only if this entry exists
> the Addons.xcu the extension has to be updated.
>>
>> This might be error prone, because the file can have any name, all
>> it matters is the media type in the META-INF manifest and the OO
>> registry package and name in the file itself.
>>
>> While it's highly rare to find a lala.lala, I've found an
>> "addons.xcu" (in lowercase). No wonder there is no OfficeToolBar in
>> this particular extension, but the extension does not work in AOO
>> 4.0 due to API changes (what shows that the whole discussion
>> centered on the schema change is full of ungrounded assumptions,
>> and lack of knowledge on the subject).
>
> ignore case is probably a good idea, a complete different name is
> probably rather seldom. But from a technical point of view you are
> correct.
>
> We don't need exact data but it would be nice to get an impression how
> often it is used.
>
> Juergen
>
>>
>>
 242 extensions contain  addons.xcu stensioni (total: 1065
 releases), 430 estensions don't (total: 1660 releases). Do you
 want us to check how many contain OfficeToolBar?
>>>
>>> If you could run a short script to check it, it would be very
>>> useful for us to make a final decision.

Officetoolbar used within 137 extensions (553 releases).

>>>
>>> Maybe you can also provide some numbers about their downloads.
>>> Only th extensions that contain an Addons.xcu with OfficeToolBar

That's not really trivial, but it would be easier to figure out how
many among top 50 contain Addons.xcu with OfficeToolBar.

Would it make the trick? If not I'll work on how to compute those numbers.

Let me know,

Roberto


>> It would also be interesting to know the last time the extension
>> was updated; besides that expecting unmaintained extensions to work
>> on a new major release might not be plausible, the extension is
>> likely not be adapted to any change if it is unmaintained, no
>> matter how popular it is (example: the most popular, Oracle PDF
>> Import Extension, Downloads: Week: 12,706, unmaintained since Dec.
>> 2010, seems to be broken - according to the first three comments).
>>
>>
>> Regards
>>
>

-- 

This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/21/13 10:05 AM, Ariel Constenla-Haile wrote:
> On Thu, Feb 21, 2013 at 09:22:34AM +0100, Jürgen Schmidt wrote:
 The first step should be a simple check if an Addons.xcu is
 contained at all. Something like "unzip -l  | grep
 Addons.xcu" should be enough. The second step if an
 Addons.xcu is contained is to check for the ">>> oor:name="OfficeToolBar">" entry. Only if this entry exists 
 the Addons.xcu the extension has to be updated.
> 
> This might be error prone, because the file can have any name, all
> it matters is the media type in the META-INF manifest and the OO
> registry package and name in the file itself.
> 
> While it's highly rare to find a lala.lala, I've found an
> "addons.xcu" (in lowercase). No wonder there is no OfficeToolBar in
> this particular extension, but the extension does not work in AOO
> 4.0 due to API changes (what shows that the whole discussion
> centered on the schema change is full of ungrounded assumptions,
> and lack of knowledge on the subject).

ignore case is probably a good idea, a complete different name is
probably rather seldom. But from a technical point of view you are
correct.

We don't need exact data but it would be nice to get an impression how
often it is used.

Juergen

> 
> 
>>> 242 extensions contain  addons.xcu stensioni (total: 1065
>>> releases), 430 estensions don't (total: 1660 releases). Do you
>>> want us to check how many contain OfficeToolBar?
>> 
>> If you could run a short script to check it, it would be very
>> useful for us to make a final decision.
>> 
>> Maybe you can also provide some numbers about their downloads.
>> Only th extensions that contain an Addons.xcu with OfficeToolBar
> 
> It would also be interesting to know the last time the extension
> was updated; besides that expecting unmaintained extensions to work
> on a new major release might not be plausible, the extension is
> likely not be adapted to any change if it is unmaintained, no
> matter how popular it is (example: the most popular, Oracle PDF
> Import Extension, Downloads: Week: 12,706, unmaintained since Dec.
> 2010, seems to be broken - according to the first three comments).
> 
> 
> Regards
> 

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Joost Andrae]

Hi,



It would also be interesting to know the last time the extension was
updated; besides that expecting unmaintained extensions to work on a new
major release might not be plausible, the extension is likely not be
adapted to any change if it is unmaintained, no matter how popular it is
(example: the most popular, Oracle PDF Import Extension, Downloads:
Week: 12,706, unmaintained since Dec. 2010, seems to be broken
- according to the first three comments).


within the last days I've installed the Windows variant of the PDF 
Import Extension several times on different systems (Win7, Win8) and all 
of those installations worked like a charm.


Kind regards, Joost

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Ariel Constenla-Haile]

On Thu, Feb 21, 2013 at 09:22:34AM +0100, Jürgen Schmidt wrote:
> >> The first step should be a simple check if an Addons.xcu is contained at
> >> all. Something like "unzip -l  | grep Addons.xcu" should be
> >> enough. The second step if an Addons.xcu is contained is to check for
> >> the "" entry. Only if this entry exists
> >> the Addons.xcu the extension has to be updated.

This might be error prone, because the file can have any name, all it
matters is the media type in the META-INF manifest and the OO registry
package and name in the file itself.

While it's highly rare to find a lala.lala, I've found an "addons.xcu"
(in lowercase). No wonder there is no OfficeToolBar in this particular
extension, but the extension does not work in AOO 4.0 due to API changes
(what shows that the whole discussion centered on the schema change is
full of ungrounded assumptions, and lack of knowledge on the subject).

 
> > 242 extensions contain  addons.xcu stensioni (total: 1065 releases), 430
> > estensions don't (total: 1660 releases). Do you want us to check how many
> > contain OfficeToolBar?
> 
> If you could run a short script to check it, it would be very useful for
> us to make a final decision.
> 
> Maybe you can also provide some numbers about their downloads. Only th
> extensions that contain an Addons.xcu with OfficeToolBar

It would also be interesting to know the last time the extension was
updated; besides that expecting unmaintained extensions to work on a new
major release might not be plausible, the extension is likely not be
adapted to any change if it is unmaintained, no matter how popular it is
(example: the most popular, Oracle PDF Import Extension, Downloads:
Week: 12,706, unmaintained since Dec. 2010, seems to be broken
- according to the first three comments).


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpBotwNCYCTn.pgp
Description: PGP signature

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/20/13 8:14 PM, Roberto Galoppini wrote:
> On Mon, Feb 18, 2013 at 8:41 AM, Jürgen Schmidt wrote:
> 
>> On 2/17/13 10:36 AM, Andrea Pescetti wrote:
>>> On 12/02/2013 Jürgen Schmidt wrote:
 If we support both the
 underlying code would be more complex, slower and more ugly to maintain.
>>>
>>> OK. I had understood this part, so let's have a detailed description of
>>> the impact before we see how to handle this.
>>>
 The whole discussion is really based on assumption. We can ask our
 friends of SourceForge to analyze by a script all extensions and check
 if they contain an Addon.xcu or not. All developers, maintainers of
 extensions with Addon.xcu can we contact and can inform them about the
 proposed change and how to adapt the xcu.
>>>
>>> Good ideas, and we could maybe consider to add an "Outdated" notice,
>>> similar to the wiki pages, to extensions that contain an Addons.xcu.
>>>
>>> So, to start getting some facts, what should the script do? Unzip the
>>> extension and look in the expanded tree for a file named exactly
>>> "Addons.xcu" (not "Addon.xcu", right)?
>>
>> The first step should be a simple check if an Addons.xcu is contained at
>> all. Something like "unzip -l  | grep Addons.xcu" should be
>> enough. The second step if an Addons.xcu is contained is to check for
>> the "" entry. Only if this entry exists
>> the Addons.xcu the extension has to be updated.
>>
> 
> 242 extensions contain  addons.xcu stensioni (total: 1065 releases), 430
> estensions don't (total: 1660 releases). Do you want us to check how many
> contain OfficeToolBar?

If you could run a short script to check it, it would be very useful for
us to make a final decision.

Maybe you can also provide some numbers about their downloads. Only th
extensions that contain an Addons.xcu with OfficeToolBar


Juergen


> 
> Roberto
> 
>>
>> I will provide an example showing the change as part of the
>> http://wiki.openoffice.org/wiki/API/Incompatible_API_changes
>>
>> See also
>> http://wiki.openoffice.org/wiki/API
>> http://wiki.openoffice.org/wiki/API/Concepts_API_changes
>>
>>
>> Shall we also ask to check how
>>> many extensions provide an "OpenOffice.org-maximal-version" parameter as
>>> listed at
>>>
>> http://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Description_of_XML_Elements
>>> ?
>>
>> make sense but it is not necessary, this is something that the extension
>> developer should decide. It's a recommendation to use it to ensure that
>> an extension works with the next version. It can be seen as part of the
>> QA for a serious extension ;-)
>>
>>
>>>
>>> In light of Ariel's detailed analysis of the Oracle extensions
>>> (thanks!), what does
   Addons.cxu but *only* with "OfficeMenuBarMerging" node
>>> mean? I assume you meant "Addons.xcu", but what does "only with
>>> OfficeMenuBarMerging node" mean? That these extensions will not be
>>> affected by this particular change? Or that updating them will be easier?
>>
>> exactly, we have 2 ways to integrate here. One is to create a completely
>> new toolbar with a new name. And the second one is to merge into
>> existing toolbars at a specific position. This can be very useful and is
>> not affected by this change.
>>
>>>
>>> We will have other elements to consider before assessing the impact on
>>> users (for example, the website does not currently filter by OpenOffice
>>> version; and some popular extensions, like LanguageTool, are not hosted
>>> in the official repository), but it's very good if we can have some real
>>> numbers to start.
>>
>> well we can of course blow up this to whatever we want. There is a lot
>> of room for improvements in many areas. We should not mix too many things.
>>
>> An improved extension repo with a hopefully working extension update
>> mechanism. Here extensions that are not supported for 4.0 could be
>> already filtered on the server and there is no demand to transport any
>> info about this extensions to a 4.0 office.
>>
>> An improved extension mechanism where we would have an improved workflow
>> and more features. Browsing extensions directly from the office, a
>> configurable extension repo, dependencies to other extensions, ...
>>
>> Juergen
>>
>>
>>
> 

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Roberto Galoppini]

On Mon, Feb 18, 2013 at 8:41 AM, Jürgen Schmidt wrote:

> On 2/17/13 10:36 AM, Andrea Pescetti wrote:
> > On 12/02/2013 Jürgen Schmidt wrote:
> >> If we support both the
> >> underlying code would be more complex, slower and more ugly to maintain.
> >
> > OK. I had understood this part, so let's have a detailed description of
> > the impact before we see how to handle this.
> >
> >> The whole discussion is really based on assumption. We can ask our
> >> friends of SourceForge to analyze by a script all extensions and check
> >> if they contain an Addon.xcu or not. All developers, maintainers of
> >> extensions with Addon.xcu can we contact and can inform them about the
> >> proposed change and how to adapt the xcu.
> >
> > Good ideas, and we could maybe consider to add an "Outdated" notice,
> > similar to the wiki pages, to extensions that contain an Addons.xcu.
> >
> > So, to start getting some facts, what should the script do? Unzip the
> > extension and look in the expanded tree for a file named exactly
> > "Addons.xcu" (not "Addon.xcu", right)?
>
> The first step should be a simple check if an Addons.xcu is contained at
> all. Something like "unzip -l  | grep Addons.xcu" should be
> enough. The second step if an Addons.xcu is contained is to check for
> the "" entry. Only if this entry exists
> the Addons.xcu the extension has to be updated.
>

242 extensions contain  addons.xcu stensioni (total: 1065 releases), 430
estensions don't (total: 1660 releases). Do you want us to check how many
contain OfficeToolBar?

Roberto

>
> I will provide an example showing the change as part of the
> http://wiki.openoffice.org/wiki/API/Incompatible_API_changes
>
> See also
> http://wiki.openoffice.org/wiki/API
> http://wiki.openoffice.org/wiki/API/Concepts_API_changes
>
>
> Shall we also ask to check how
> > many extensions provide an "OpenOffice.org-maximal-version" parameter as
> > listed at
> >
> http://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Description_of_XML_Elements
> > ?
>
> make sense but it is not necessary, this is something that the extension
> developer should decide. It's a recommendation to use it to ensure that
> an extension works with the next version. It can be seen as part of the
> QA for a serious extension ;-)
>
>
> >
> > In light of Ariel's detailed analysis of the Oracle extensions
> > (thanks!), what does
> >>   Addons.cxu but *only* with "OfficeMenuBarMerging" node
> > mean? I assume you meant "Addons.xcu", but what does "only with
> > OfficeMenuBarMerging node" mean? That these extensions will not be
> > affected by this particular change? Or that updating them will be easier?
>
> exactly, we have 2 ways to integrate here. One is to create a completely
> new toolbar with a new name. And the second one is to merge into
> existing toolbars at a specific position. This can be very useful and is
> not affected by this change.
>
> >
> > We will have other elements to consider before assessing the impact on
> > users (for example, the website does not currently filter by OpenOffice
> > version; and some popular extensions, like LanguageTool, are not hosted
> > in the official repository), but it's very good if we can have some real
> > numbers to start.
>
> well we can of course blow up this to whatever we want. There is a lot
> of room for improvements in many areas. We should not mix too many things.
>
> An improved extension repo with a hopefully working extension update
> mechanism. Here extensions that are not supported for 4.0 could be
> already filtered on the server and there is no demand to transport any
> info about this extensions to a 4.0 office.
>
> An improved extension mechanism where we would have an improved workflow
> and more features. Browsing extensions directly from the office, a
> configurable extension repo, dependencies to other extensions, ...
>
> Juergen
>
>
>

-- 

This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/17/13 10:36 AM, Andrea Pescetti wrote:
> On 12/02/2013 Jürgen Schmidt wrote:
>> If we support both the
>> underlying code would be more complex, slower and more ugly to maintain.
> 
> OK. I had understood this part, so let's have a detailed description of
> the impact before we see how to handle this.
> 
>> The whole discussion is really based on assumption. We can ask our
>> friends of SourceForge to analyze by a script all extensions and check
>> if they contain an Addon.xcu or not. All developers, maintainers of
>> extensions with Addon.xcu can we contact and can inform them about the
>> proposed change and how to adapt the xcu.
> 
> Good ideas, and we could maybe consider to add an "Outdated" notice,
> similar to the wiki pages, to extensions that contain an Addons.xcu.
> 
> So, to start getting some facts, what should the script do? Unzip the
> extension and look in the expanded tree for a file named exactly
> "Addons.xcu" (not "Addon.xcu", right)? 

The first step should be a simple check if an Addons.xcu is contained at
all. Something like "unzip -l  | grep Addons.xcu" should be
enough. The second step if an Addons.xcu is contained is to check for
the "" entry. Only if this entry exists
the Addons.xcu the extension has to be updated.

I will provide an example showing the change as part of the
http://wiki.openoffice.org/wiki/API/Incompatible_API_changes

See also
http://wiki.openoffice.org/wiki/API
http://wiki.openoffice.org/wiki/API/Concepts_API_changes


Shall we also ask to check how
> many extensions provide an "OpenOffice.org-maximal-version" parameter as
> listed at
> http://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Description_of_XML_Elements
> ?

make sense but it is not necessary, this is something that the extension
developer should decide. It's a recommendation to use it to ensure that
an extension works with the next version. It can be seen as part of the
QA for a serious extension ;-)


> 
> In light of Ariel's detailed analysis of the Oracle extensions
> (thanks!), what does
>>   Addons.cxu but *only* with "OfficeMenuBarMerging" node
> mean? I assume you meant "Addons.xcu", but what does "only with
> OfficeMenuBarMerging node" mean? That these extensions will not be
> affected by this particular change? Or that updating them will be easier?

exactly, we have 2 ways to integrate here. One is to create a completely
new toolbar with a new name. And the second one is to merge into
existing toolbars at a specific position. This can be very useful and is
not affected by this change.

> 
> We will have other elements to consider before assessing the impact on
> users (for example, the website does not currently filter by OpenOffice
> version; and some popular extensions, like LanguageTool, are not hosted
> in the official repository), but it's very good if we can have some real
> numbers to start.

well we can of course blow up this to whatever we want. There is a lot
of room for improvements in many areas. We should not mix too many things.

An improved extension repo with a hopefully working extension update
mechanism. Here extensions that are not supported for 4.0 could be
already filtered on the server and there is no demand to transport any
info about this extensions to a 4.0 office.

An improved extension mechanism where we would have an improved workflow
and more features. Browsing extensions directly from the office, a
configurable extension repo, dependencies to other extensions, ...

Juergen

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Fernando Cassia]

On Mon, Feb 11, 2013 at 6:46 PM, Rob Weir  wrote:
> My impression was that even if we made no changes, from the user's
> perspective, they would lose all extensions.  This is due to the
> change in base directory for the profile.  So all extensions would be
> lost and need to be reinstalled.  So there will be no doubt in the
> user's mind, even if they do not read the release notes, that the
> extensions are gone.

Just copy the Firefox way A dialog reading something like "Oh,
we´ve detected some extesions, checking for compatibility with 4.0..."
followed by "the following extensions are not compatible with 4.0 and
have been disabled, you might want to check [url] for newer versions
compatible with 4.0".

Of course, automated checking of each extension on a central database
(like FF does) would be great, but the half-solution (informative
message) above is better than nothing.
Just my $0.02
FC

-- 
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un
Acto Revolucionario
- George Orwell

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Andrea Pescetti]

On 12/02/2013 Jürgen Schmidt wrote:

If we support both the
underlying code would be more complex, slower and more ugly to maintain.


OK. I had understood this part, so let's have a detailed description of 
the impact before we see how to handle this.



The whole discussion is really based on assumption. We can ask our
friends of SourceForge to analyze by a script all extensions and check
if they contain an Addon.xcu or not. All developers, maintainers of
extensions with Addon.xcu can we contact and can inform them about the
proposed change and how to adapt the xcu.


Good ideas, and we could maybe consider to add an "Outdated" notice, 
similar to the wiki pages, to extensions that contain an Addons.xcu.


So, to start getting some facts, what should the script do? Unzip the 
extension and look in the expanded tree for a file named exactly 
"Addons.xcu" (not "Addon.xcu", right)? Shall we also ask to check how 
many extensions provide an "OpenOffice.org-maximal-version" parameter as 
listed at 
http://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Description_of_XML_Elements 
?


In light of Ariel's detailed analysis of the Oracle extensions 
(thanks!), what does

  Addons.cxu but *only* with "OfficeMenuBarMerging" node
mean? I assume you meant "Addons.xcu", but what does "only with 
OfficeMenuBarMerging node" mean? That these extensions will not be 
affected by this particular change? Or that updating them will be easier?


We will have other elements to consider before assessing the impact on 
users (for example, the website does not currently filter by OpenOffice 
version; and some popular extensions, like LanguageTool, are not hosted 
in the official repository), but it's very good if we can have some real 
numbers to start.


Regards,
  Andrea.

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Tue, Feb 12, 2013 at 5:31 PM, Hagar Delest  wrote:
> Le 12/02/2013 13:05, Rob Weir a écrit :
>
>> I don't know.  I was asking a question.  But I think this is an
>> important question:  Why would an extension author not update their
>> extension for AOO 4.0?  Some hypothetical answers:
>>
>> 1) The extension is unmaintained
>
>
> One of the top reasons I guess. I myslef made extensions for my own use. I
> would have to tweak it. Since I've done them some time ago, I would have to
> dive again in specifications to make the changes.
>
>
>
>> 2)  The author cannot be located or we have no way to notify them of
>> changes
>
>
> May be related to 1).
>
>
>
>> 3) It is not clear to the author what technical changes are needed
>
>
> Was a communication plan issued to warn the authors about that?
> Don't tell me the release notes are for that. Almost nobody read the release
> notes (at least until the end).
> I guess that many extensions mlaintainers don't follow this dev list at all.
>

No, no.  The Release Notes are just what I proposed to collect these
kinds of items.  If we actually make breaking changes I'd expect to
see a bigger attempt to reach out to extension authors:

1) blog post

2) post to API list and forum

3) maybe banner on the extensions website itself

But this would make more sense after the changes are made and when we
can point to complete instructions as well as developer snaphot build
that the author can use to test their modifications.

What is not clear is how much notice is needed.  1 month?  2 months?  More?

-Rob


>
>
>> 4) There is not sufficient calendar time for the extension author to
>> make the needed changes before we release, or the work required is too
>> much for the author to fit into his schedule
>
>
> May be related to 3). Without any warning, few chances to implement any
> change.
>
>
>
>> 5) The author attempts changes but they don't work or they introduce
>> new problems
>
>
> Rather unlikely.
>
>
>
>> 6) The results of not making the changes is not clear, so the author
>> mistakenly thinks they are optional changes
>
>
> Or he just don't care anymore about the extension. So it needs to be taken
> over by someone else. But how we could know that?
>
>
>
>> 7) Author has technical or account issues with the extensions website
>> and is unable to upload a new version, and does not know where to get
>> help.
>>
>> These are all possible concerns, but I think most of them can be
>> managed with good communications and advance notice.
>>
>> There is also the possibility of:
>>
>> 8) Inconvenience -- it is natural for anyone to complain about needing
>> to do additional work where they don't see the advantage.  So it is
>> natural that we will expect complaints, followed in the end by
>> conformance with the required changes.
>
>
> Yes but what about the loss of confidence from users who will be first
> frustrated by an upgrade that breaks more things than fix them? Then they
> will have to do some homework to find out what the problem is (again, don't
> tell me about release notes). And wait in the end for someone to fix it.
> What if they do need their extensions meanwhile?
>
> One side aspect: what about extension update warning? If a new version is
> detected but the user doesn't upgrade to 4.0, are we sure that the minimal
> version will be checked first, before the new extension is installed by the
> user? Has he to download it before being warned that it's in fact not
> compatible with his current AOO/OOo version?
>
> I'm not against the change. I'm for a controlled one, that has no impact on
> end-users. So the main points are: communication to the extensions
> maintainers (what about the extensions hosted on their personal pages and
> not on sourceforge?), preparation of the updates and transition period.
>
> Hagar

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Hagar Delest]

Le 12/02/2013 13:05, Rob Weir a écrit :

I don't know.  I was asking a question.  But I think this is an
important question:  Why would an extension author not update their
extension for AOO 4.0?  Some hypothetical answers:

1) The extension is unmaintained


One of the top reasons I guess. I myslef made extensions for my own use. I 
would have to tweak it. Since I've done them some time ago, I would have to 
dive again in specifications to make the changes.



2)  The author cannot be located or we have no way to notify them of changes


May be related to 1).



3) It is not clear to the author what technical changes are needed


Was a communication plan issued to warn the authors about that?
Don't tell me the release notes are for that. Almost nobody read the release 
notes (at least until the end).
I guess that many extensions mlaintainers don't follow this dev list at all.



4) There is not sufficient calendar time for the extension author to
make the needed changes before we release, or the work required is too
much for the author to fit into his schedule


May be related to 3). Without any warning, few chances to implement any change.



5) The author attempts changes but they don't work or they introduce
new problems


Rather unlikely.



6) The results of not making the changes is not clear, so the author
mistakenly thinks they are optional changes


Or he just don't care anymore about the extension. So it needs to be taken over 
by someone else. But how we could know that?



7) Author has technical or account issues with the extensions website
and is unable to upload a new version, and does not know where to get
help.

These are all possible concerns, but I think most of them can be
managed with good communications and advance notice.

There is also the possibility of:

8) Inconvenience -- it is natural for anyone to complain about needing
to do additional work where they don't see the advantage.  So it is
natural that we will expect complaints, followed in the end by
conformance with the required changes.


Yes but what about the loss of confidence from users who will be first 
frustrated by an upgrade that breaks more things than fix them? Then they will 
have to do some homework to find out what the problem is (again, don't tell me 
about release notes). And wait in the end for someone to fix it. What if they 
do need their extensions meanwhile?

One side aspect: what about extension update warning? If a new version is 
detected but the user doesn't upgrade to 4.0, are we sure that the minimal 
version will be checked first, before the new extension is installed by the 
user? Has he to download it before being warned that it's in fact not 
compatible with his current AOO/OOo version?

I'm not against the change. I'm for a controlled one, that has no impact on 
end-users. So the main points are: communication to the extensions maintainers 
(what about the extensions hosted on their personal pages and not on 
sourceforge?), preparation of the updates and transition period.

Hagar

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Ariel Constenla-Haile]

On Tue, Feb 12, 2013 at 01:42:42PM +0100, Joost Andrae wrote:
> Hi,
> 
> in the moment I have just one question in mind:
> 
> Who's going to adapt the Sun/Oracle extensions that contain
> Addons.xcu like presentation-minimizer.oxt ?

This extension does not provide a toolbar of its own, it uses only
menubar merging.


This is the situation of Oracle extensions:

* No longer maintained:

- Oracle PDF Import Extension (Nr. 1 in popularity)
  http://extensions.openoffice.org/en/project/pdfimport
  2008-Oct-29
  No Addons.xcu
  Only OpenOffice.org-minimal-version value="3.0"
  Reading the comments on the extension site, it seems quite broken.
  Link to the old OOo mailing list should be removed
  Incompatible license in dependencies

- MySQL Connector for OpenOffice.org (Nr. 13 in popularity)
  http://extensions.openoffice.org/en/project/mysql_connector
  2011-Jan-05
  No Addons.xcu
  Only OpenOffice.org-minimal-version value="3.1"
  Incompatible license in dependencies

- Oracle Report Builder (Nr. 15 in popularity)
  http://extensions.openoffice.org/en/project/reportdesign
  2010-Dec-14
  No Addons.xcu
  Only OpenOffice.org-minimal-version value="3.2"
  Incompatible license in dependencies


* Still maintained:

- Oracle Presenter Console (Nr. 22 in popularity)
  http://extensions.openoffice.org/en/project/presenter-screen
  2010-Nov-25
  No Addons.xcu
  Only OpenOffice.org-minimal-version value="3.3"
  Compatible license

- Oracle Presentation Minimizer (Nr. 35 in popularity)
  http://extensions.openoffice.org/en/project/PresentationMinimizer
  2010-Nov-21
  Addons.cxu but *only* with "OfficeMenuBarMerging" node
  Only OpenOffice.org-minimal-version value="2.3"
  Compatible license

- Sun Wiki Publisher
  http://extensions.services.openoffice.org/en/project/wikipublisher
  2009-Jun-09
  Addons.cxu but *only* with "OfficeMenuBarMerging" node
  Only OpenOffice.org-minimal-version value="3.0"
  Compatible license



Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpxmpVJMhKE6.pgp
Description: PGP signature

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rory O'Farrell]

On Tue, 12 Feb 2013 15:06:27 +0100
Jürgen Schmidt  wrote:

> On 2/12/13 2:15 PM, Rory O'Farrell wrote:
> > On Tue, 12 Feb 2013 14:07:59 +0100
> > Jürgen Schmidt  wrote:
> > 
> >> On 2/12/13 1:42 PM, Joost Andrae wrote:
> >>> Hi,
> >>>
> >>> in the moment I have just one question in mind:
> >>>
> >>> Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu
> >>> like presentation-minimizer.oxt ?
> >>
> >> well the extensions where we have the source code can be changed by
> >> volunteers. Maybe directly at Apache or as Google code project when
> >> there are license incompatible dependencies.
> >>
> >> Everything else is unclear and I doubt that Oracle has interest in
> >> updating them. And nobody else can do that.
> >>
> >> The best thing would be to start new projects providing similar
> >> functionality but where the code is available and under a proper license.
> >>
> >> Unmaintained extensions are a general problem and should not have
> >> influence on any decision.
> > 
> > There are already reports on incompatabilities with LibO 4.0 and some 
> > existing extensions.  
> > 
> > One thread, for example, at
> > http://forum.openoffice.org/en/forum/viewtopic.php?f=101&t=59595
> > 
> > Might there be possibility for a shim to be written to sit between 
> > Addons.xcu and AOO 4.0?
> 
> I don't know, I haven't looked into it but I know that they have changed
> API's more radical. No surprise for me.
> 

The posting was just for information; it will be interesting to monitor how 
serious a problem it is for their implementation, and how they cope with it.

-- 
Rory O'Farrell 

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/12/13 2:15 PM, Rory O'Farrell wrote:
> On Tue, 12 Feb 2013 14:07:59 +0100
> Jürgen Schmidt  wrote:
> 
>> On 2/12/13 1:42 PM, Joost Andrae wrote:
>>> Hi,
>>>
>>> in the moment I have just one question in mind:
>>>
>>> Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu
>>> like presentation-minimizer.oxt ?
>>
>> well the extensions where we have the source code can be changed by
>> volunteers. Maybe directly at Apache or as Google code project when
>> there are license incompatible dependencies.
>>
>> Everything else is unclear and I doubt that Oracle has interest in
>> updating them. And nobody else can do that.
>>
>> The best thing would be to start new projects providing similar
>> functionality but where the code is available and under a proper license.
>>
>> Unmaintained extensions are a general problem and should not have
>> influence on any decision.
> 
> There are already reports on incompatabilities with LibO 4.0 and some 
> existing extensions.  
> 
> One thread, for example, at
> http://forum.openoffice.org/en/forum/viewtopic.php?f=101&t=59595
> 
> Might there be possibility for a shim to be written to sit between Addons.xcu 
> and AOO 4.0?

I don't know, I haven't looked into it but I know that they have changed
API's more radical. No surprise for me.

Juergen

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rory O'Farrell]

On Tue, 12 Feb 2013 14:07:59 +0100
Jürgen Schmidt  wrote:

> On 2/12/13 1:42 PM, Joost Andrae wrote:
> > Hi,
> > 
> > in the moment I have just one question in mind:
> > 
> > Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu
> > like presentation-minimizer.oxt ?
> 
> well the extensions where we have the source code can be changed by
> volunteers. Maybe directly at Apache or as Google code project when
> there are license incompatible dependencies.
> 
> Everything else is unclear and I doubt that Oracle has interest in
> updating them. And nobody else can do that.
> 
> The best thing would be to start new projects providing similar
> functionality but where the code is available and under a proper license.
> 
> Unmaintained extensions are a general problem and should not have
> influence on any decision.

There are already reports on incompatabilities with LibO 4.0 and some existing 
extensions.  

One thread, for example, at
http://forum.openoffice.org/en/forum/viewtopic.php?f=101&t=59595

Might there be possibility for a shim to be written to sit between Addons.xcu 
and AOO 4.0?

-- 
Rory O'Farrell 

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/12/13 1:42 PM, Joost Andrae wrote:
> Hi,
> 
> in the moment I have just one question in mind:
> 
> Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu
> like presentation-minimizer.oxt ?

well the extensions where we have the source code can be changed by
volunteers. Maybe directly at Apache or as Google code project when
there are license incompatible dependencies.

Everything else is unclear and I doubt that Oracle has interest in
updating them. And nobody else can do that.

The best thing would be to start new projects providing similar
functionality but where the code is available and under a proper license.

Unmaintained extensions are a general problem and should not have
influence on any decision.

Juergen


> 
>>
>> 8) Inconvenience -- it is natural for anyone to complain about needing
>> to do additional work where they don't see the advantage.  So it is
>> natural that we will expect complaints, followed in the end by
>> conformance with the required changes.
>>
>> What is totally unclear to me is whether we are facing #8 only, or
>> whether we have any of the other concerns.
>>
>> One option for #8 is to add a nice new feature or capability to the
>> API so extension author will *want* to update.
> 
> Kind regards, Joost
> 

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Joost Andrae]

Hi,

in the moment I have just one question in mind:

Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu 
like presentation-minimizer.oxt ?




8) Inconvenience -- it is natural for anyone to complain about needing
to do additional work where they don't see the advantage.  So it is
natural that we will expect complaints, followed in the end by
conformance with the required changes.

What is totally unclear to me is whether we are facing #8 only, or
whether we have any of the other concerns.

One option for #8 is to add a nice new feature or capability to the
API so extension author will *want* to update.


Kind regards, Joost

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Tue, Feb 12, 2013 at 4:11 AM, Jürgen Schmidt  wrote:
> On 2/12/13 12:41 AM, Rob Weir wrote:
>> On Mon, Feb 11, 2013 at 5:37 PM, Hagar Delest  
>> wrote:
>>> Le 11/02/2013 22:46, Rob Weir a écrit :

 My impression was that even if we made no changes, from the user's
 perspective, they would lose all extensions.  This is due to the
 change in base directory for the profile.  So all extensions would be
 lost and need to be reinstalled.  So there will be no doubt in the
 user's mind, even if they do not read the release notes, that the
 extensions are gone.
 [...]

 Again, my impression is that users will lose their extensions and need
 to reinstall them, even if we do not make any API changes.
 [...]

 I think a "clean break" with the past profile helps us avoid the
 current generation of crash issues.  We get to start clean rather than
 deal with the many upgrade paths:
>>>
>>>
>>> No real problem with reinstalling extensions after a major upgrade, I've
>>> done that too.
>>> But there is a difference between the mere inconvenience of reinstalling
>>> extensions and losing them completely (waiting that someone dare update
>>> them).
>>>
>>
>> Is that what we're really facing?  Are you saying that extension
>> author will not update their extensions if they become incompatible?
>> Is that what we think?
>>
>> I agree that this would be a bad situation.  But is it the likely
>> situation we would face?  The authors of the top extensions would not
>> update?
>
> If that is the case than we can stop to talk about extensions at all. I
> would not spent any further minute to make the life of extension
> developers easier.
>

I don't know.  I was asking a question.  But I think this is an
important question:  Why would an extension author not update their
extension for AOO 4.0?  Some hypothetical answers:

1) The extension is unmaintained

2)  The author cannot be located or we have no way to notify them of changes

3) It is not clear to the author what technical changes are needed

4) There is not sufficient calendar time for the extension author to
make the needed changes before we release, or the work required is too
much for the author to fit into his schedule

5) The author attempts changes but they don't work or they introduce
new problems

6) The results of not making the changes is not clear, so the author
mistakenly thinks they are optional changes

7) Author has technical or account issues with the extensions website
and is unable to upload a new version, and does not know where to get
help.

These are all possible concerns, but I think most of them can be
managed with good communications and advance notice.

There is also the possibility of:

8) Inconvenience -- it is natural for anyone to complain about needing
to do additional work where they don't see the advantage.  So it is
natural that we will expect complaints, followed in the end by
conformance with the required changes.

What is totally unclear to me is whether we are facing #8 only, or
whether we have any of the other concerns.

One option for #8 is to add a nice new feature or capability to the
API so extension author will *want* to update.

-Rob

> Juergen

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/12/13 12:41 AM, Rob Weir wrote:
> On Mon, Feb 11, 2013 at 5:37 PM, Hagar Delest  
> wrote:
>> Le 11/02/2013 22:46, Rob Weir a écrit :
>>>
>>> My impression was that even if we made no changes, from the user's
>>> perspective, they would lose all extensions.  This is due to the
>>> change in base directory for the profile.  So all extensions would be
>>> lost and need to be reinstalled.  So there will be no doubt in the
>>> user's mind, even if they do not read the release notes, that the
>>> extensions are gone.
>>> [...]
>>>
>>> Again, my impression is that users will lose their extensions and need
>>> to reinstall them, even if we do not make any API changes.
>>> [...]
>>>
>>> I think a "clean break" with the past profile helps us avoid the
>>> current generation of crash issues.  We get to start clean rather than
>>> deal with the many upgrade paths:
>>
>>
>> No real problem with reinstalling extensions after a major upgrade, I've
>> done that too.
>> But there is a difference between the mere inconvenience of reinstalling
>> extensions and losing them completely (waiting that someone dare update
>> them).
>>
> 
> Is that what we're really facing?  Are you saying that extension
> author will not update their extensions if they become incompatible?
> Is that what we think?
> 
> I agree that this would be a bad situation.  But is it the likely
> situation we would face?  The authors of the top extensions would not
> update?

If that is the case than we can stop to talk about extensions at all. I
would not spent any further minute to make the life of extension
developers easier.

Juergen

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/12/13 12:03 AM, Andrea Pescetti wrote:
> On 11/02/2013 Hagar Delest wrote:
>> No real problem with reinstalling extensions after a major upgrade, I've
>> done that too.
>> But there is a difference between the mere inconvenience of reinstalling
>> extensions and losing them completely (waiting that someone dare update
>> them).
> 
> The real issue is here indeed. Reinstalling won't be perceived as a big
> problem. But the fact that reinstalling the same extension won't work
> will be a problem.
> 
> Most of the extensions hosted on extensions.openoffice.org won't be
> updated, and extensions.openoffice.org does not support filtering by
> version (and anyway the information would be missing in current
> releases). The top five extensions at
> http://extensions.openoffice.org/en/most_popular
> total 1 million downloads per year, which could give some backing to the
> nightmare support scenario Hagar envisions.
> 
> Ariel posted to the API list saying that the two reasonable options in
> his opinion are either to keep or revert his entire change (Hagar,
> please note that Ariel asked not to start a discussion here and now, and
> mentioned he cannot be responsive at the moment; anyway...). But if
> there is a way, even using redundant code, to still support the old and
> new toolbar handling this would be very useful to end-users. From the
> FOSDEM talks I understood there could the possibility to still support
> both mechanisms (and of course, warn users when the "deprecated" one is
> used).

maybe you understand it wrong, no warning. If we support both the
underlying code would be more complex, slower and more ugly to maintain.
and Ariel pointed already out that he is not willing to support both
based on this fact. Either the old or the new mechanism, or somebody
else step forward and implement the change.

The whole discussion is really based on assumption. We can ask our
friends of SourceForge to analyze by a script all extensions and check
if they contain an Addon.xcu or not. All developers, maintainers of
extensions with Addon.xcu can we contact and can inform them about the
proposed change and how to adapt the xcu.

Juergen

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Mon, Feb 11, 2013 at 6:46 PM, Rob Weir  wrote:
> On Mon, Feb 11, 2013 at 6:03 PM, Andrea Pescetti  wrote:
>> On 11/02/2013 Hagar Delest wrote:
>>>
>>> No real problem with reinstalling extensions after a major upgrade, I've
>>> done that too.
>>> But there is a difference between the mere inconvenience of reinstalling
>>> extensions and losing them completely (waiting that someone dare update
>>> them).
>>
>>
>> The real issue is here indeed. Reinstalling won't be perceived as a big
>> problem. But the fact that reinstalling the same extension won't work will
>> be a problem.
>>
>> Most of the extensions hosted on extensions.openoffice.org won't be updated,
>> and extensions.openoffice.org does not support filtering by version (and
>> anyway the information would be missing in current releases). The top five
>> extensions at
>> http://extensions.openoffice.org/en/most_popular
>> total 1 million downloads per year, which could give some backing to the
>> nightmare support scenario Hagar envisions.
>>
>
> So you are assuming that the authors of the top extensions will not
> update their extensions?  Is that a reasonable assumption?  Why
> wouldn't they update?
>

Answering my own question:  the top downloaded extension is the PDF
Importer, and that has Oracle listed as the owner.  If this extension
is actually unmaintained, then it would be broken, yes.  Of course, if
it is unmaintained, then it is in a very fragile position now, and
almost anything can break it, from AOO changes, to platform changes to
changes in dependent libraries.  I'd say:  if we don't have a plan for
getting such extensions maintained then we should already write them
off as broken.  They will fall over when the wind blows.  It is only a
matter of time.

So my question then is:  are there any top maintained extensions where
the author would not adapt it to the proposed AOO 4.0 changes?  If
this is the case, what is their concern?  They don't like the change
from a technical perspective?  They don't have time to make the
change?  Something else?

-Rob

> I agree that if we accepted that assumption then this looks like a bad
> change.  But I do wonder about the validity of that assumption.
>
> -Rob
>
>> Ariel posted to the API list saying that the two reasonable options in his
>> opinion are either to keep or revert his entire change (Hagar, please note
>> that Ariel asked not to start a discussion here and now, and mentioned he
>> cannot be responsive at the moment; anyway...). But if there is a way, even
>> using redundant code, to still support the old and new toolbar handling this
>> would be very useful to end-users. From the FOSDEM talks I understood there
>> could the possibility to still support both mechanisms (and of course, warn
>> users when the "deprecated" one is used).
>>
>> Regards,
>>   Andrea.

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Mon, Feb 11, 2013 at 6:03 PM, Andrea Pescetti  wrote:
> On 11/02/2013 Hagar Delest wrote:
>>
>> No real problem with reinstalling extensions after a major upgrade, I've
>> done that too.
>> But there is a difference between the mere inconvenience of reinstalling
>> extensions and losing them completely (waiting that someone dare update
>> them).
>
>
> The real issue is here indeed. Reinstalling won't be perceived as a big
> problem. But the fact that reinstalling the same extension won't work will
> be a problem.
>
> Most of the extensions hosted on extensions.openoffice.org won't be updated,
> and extensions.openoffice.org does not support filtering by version (and
> anyway the information would be missing in current releases). The top five
> extensions at
> http://extensions.openoffice.org/en/most_popular
> total 1 million downloads per year, which could give some backing to the
> nightmare support scenario Hagar envisions.
>

So you are assuming that the authors of the top extensions will not
update their extensions?  Is that a reasonable assumption?  Why
wouldn't they update?

I agree that if we accepted that assumption then this looks like a bad
change.  But I do wonder about the validity of that assumption.

-Rob

> Ariel posted to the API list saying that the two reasonable options in his
> opinion are either to keep or revert his entire change (Hagar, please note
> that Ariel asked not to start a discussion here and now, and mentioned he
> cannot be responsive at the moment; anyway...). But if there is a way, even
> using redundant code, to still support the old and new toolbar handling this
> would be very useful to end-users. From the FOSDEM talks I understood there
> could the possibility to still support both mechanisms (and of course, warn
> users when the "deprecated" one is used).
>
> Regards,
>   Andrea.

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Mon, Feb 11, 2013 at 5:37 PM, Hagar Delest  wrote:
> Le 11/02/2013 22:46, Rob Weir a écrit :
>>
>> My impression was that even if we made no changes, from the user's
>> perspective, they would lose all extensions.  This is due to the
>> change in base directory for the profile.  So all extensions would be
>> lost and need to be reinstalled.  So there will be no doubt in the
>> user's mind, even if they do not read the release notes, that the
>> extensions are gone.
>> [...]
>>
>> Again, my impression is that users will lose their extensions and need
>> to reinstall them, even if we do not make any API changes.
>> [...]
>>
>> I think a "clean break" with the past profile helps us avoid the
>> current generation of crash issues.  We get to start clean rather than
>> deal with the many upgrade paths:
>
>
> No real problem with reinstalling extensions after a major upgrade, I've
> done that too.
> But there is a difference between the mere inconvenience of reinstalling
> extensions and losing them completely (waiting that someone dare update
> them).
>

Is that what we're really facing?  Are you saying that extension
author will not update their extensions if they become incompatible?
Is that what we think?

I agree that this would be a bad situation.  But is it the likely
situation we would face?  The authors of the top extensions would not
update?

-Rob

> Hagar

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Andrea Pescetti]

On 11/02/2013 Hagar Delest wrote:

No real problem with reinstalling extensions after a major upgrade, I've
done that too.
But there is a difference between the mere inconvenience of reinstalling
extensions and losing them completely (waiting that someone dare update
them).


The real issue is here indeed. Reinstalling won't be perceived as a big 
problem. But the fact that reinstalling the same extension won't work 
will be a problem.


Most of the extensions hosted on extensions.openoffice.org won't be 
updated, and extensions.openoffice.org does not support filtering by 
version (and anyway the information would be missing in current 
releases). The top five extensions at

http://extensions.openoffice.org/en/most_popular
total 1 million downloads per year, which could give some backing to the 
nightmare support scenario Hagar envisions.


Ariel posted to the API list saying that the two reasonable options in 
his opinion are either to keep or revert his entire change (Hagar, 
please note that Ariel asked not to start a discussion here and now, and 
mentioned he cannot be responsive at the moment; anyway...). But if 
there is a way, even using redundant code, to still support the old and 
new toolbar handling this would be very useful to end-users. From the 
FOSDEM talks I understood there could the possibility to still support 
both mechanisms (and of course, warn users when the "deprecated" one is 
used).


Regards,
  Andrea.

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Hagar Delest]

Le 11/02/2013 22:46, Rob Weir a écrit :

My impression was that even if we made no changes, from the user's
perspective, they would lose all extensions.  This is due to the
change in base directory for the profile.  So all extensions would be
lost and need to be reinstalled.  So there will be no doubt in the
user's mind, even if they do not read the release notes, that the
extensions are gone.
[...]
Again, my impression is that users will lose their extensions and need
to reinstall them, even if we do not make any API changes.
[...]
I think a "clean break" with the past profile helps us avoid the
current generation of crash issues.  We get to start clean rather than
deal with the many upgrade paths:


No real problem with reinstalling extensions after a major upgrade, I've done 
that too.
But there is a difference between the mere inconvenience of reinstalling 
extensions and losing them completely (waiting that someone dare update them).

Hagar

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Mon, Feb 11, 2013 at 4:10 PM, Hagar Delest  wrote:
> You certainly have seen from the 0^0 discussion that I have raised the
> problem of the backward compatibility with 4.0 and extensions. In fact, it
> affects only the extensions with a custom toolbar. But except the
> dictionaries, I guess that it makes a good deal of them still.
>
> The problem has been raised by Bernard Marcelly here:
> http://www.mail-archive.com/api@openoffice.apache.org/msg00107.html
> But as said by Ariel, this is not an API change (so shouldn't the discussion
> on the API list be dropped and discussed here instead?):
> http://www.mail-archive.com/dev@openoffice.apache.org/msg04042.html
>
> Rob has opened a wiki page related but without this topic (as for now):
> http://www.mail-archive.com/dev@openoffice.apache.org/msg03976.html
>

I added a section to the existing AOO 4.0 release notes page on the wiki:

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes

I didn't add any content to that section.

> Basically (my understanding, don't hesitate to correct me):
> - For a [minor] issue in the file structure, all the current extensions with
> a toolbar MUST be updated
> - Updated and new extensions won't be compatible with former versions of
> AOO/OOo
> For all the details, refer to the link given above.
>
> Consequences:
> - Users upgrading to 4.x will lose such extensions (certainly with no
> warning since very few users read the release notes)
> - Both versions of each extension will have to be maintained as long as
> pre-4.0 versions are still in use
>
> So, are all the committers aware of this change and do they all agree about
> such a major change?
>

My impression was that even if we made no changes, from the user's
perspective, they would lose all extensions.  This is due to the
change in base directory for the profile.  So all extensions would be
lost and need to be reinstalled.  So there will be no doubt in the
user's mind, even if they do not read the release notes, that the
extensions are gone.

Then, when extensions are installed in the fresh AOO 4.0 system, users
will need to install extensions that are compatible with AOO 4.0.

> I know that there is a topic on the API list (link given above) but I'm not
> sure it has the same audience as the dev list (number of subscribers I
> mean). Since this is a major change, I think it deserves a discussion on the
> dev mailing list.
> I know that if this change is implemented, the forums will be quickly
> flooded with users disappointed to have lost their extensions. So this is
> the topic I will point to in order to explain the dev community rationale
> about that.
>

Again, my impression is that users will lose their extensions and need
to reinstall them, even if we do not make any API changes.

> I know that code change is sometimes required. But can we take into account
> the end-user impact here? There may be some transition solution with a
> deprecated method that would be still valid for some time (let's say until
> version 5.x for example) with a massive communication to all the accounts
> having uploaded an extension?
>

I think a "clean break" with the past profile helps us avoid the
current generation of crash issues.  We get to start clean rather than
deal with the many upgrade paths:

AOO 3.4.1 -> AOO 4.0
AOO 3.4.9 -> AOO 4.0
OOo 3.3.0 -> AOO 4.0
OOo 3.2.1 -> AOO 4.0
OOo 3.2.0 -> AOO 4.0

etc.

So the reduction in complexity should improve the user experience,
once they reinstall their extensions.

The other impact, as you noted, is on the extension author.  I think
for that we need clear communications, with plenty of time for them to
adapt, plus early availability of AOO 4.0 code for them to test with.

Unlike end users, developers know that API's change, and even if they
did not change they should know that they need to retest with major
new versions.  So we should have their attention with the 4.0 release.

I don't have an opinion on changing this for 4.x versus 5.x.

-Rob

> Hagar