subject:"4.0 and loss of backward compatibility for extensions with toolbar"

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

2013-08-01 Thread Roberto Galoppini

2013/7/31 Andrea Pescetti pesce...@apache.org

 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.0http://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+Noteshttps://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.orgdev-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

2013-07-31 Thread 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

2013-07-31 Thread 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

2013-07-30 Thread Roberto Galoppini

2013/7/29 Roberto Galoppini roberto.galopp...@gmail.com




 2013/7/27 Rob Weir robw...@apache.org

 On Sat, Jul 27, 2013 at 4:59 PM, Roberto Galoppini
 roberto.galopp...@gmail.com wrote:
  2013/7/27 Rob Weir robw...@apache.org
 
  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

2013-07-30 Thread Rob Weir

On Tue, Jul 30, 2013 at 9:30 AM, Roberto Galoppini
roberto.galopp...@gmail.com wrote:
 2013/7/29 Roberto Galoppini roberto.galopp...@gmail.com




 2013/7/27 Rob Weir robw...@apache.org

 On Sat, Jul 27, 2013 at 4:59 PM, Roberto Galoppini
 roberto.galopp...@gmail.com wrote:
  2013/7/27 Rob Weir robw...@apache.org
 
  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

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

2013-07-30 Thread 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
roberto.galopp...@gmail.com wrote:

2013/7/29 Roberto Galoppini roberto.galopp...@gmail.com





2013/7/27 Rob Weir robw...@apache.org


On Sat, Jul 27, 2013 at 4:59 PM, Roberto Galoppini
roberto.galopp...@gmail.com wrote:

2013/7/27 Rob Weir robw...@apache.org


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:

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

2013-07-29 Thread Roberto Galoppini

2013/7/27 Rob Weir robw...@apache.org

 On Sat, Jul 27, 2013 at 4:59 PM, Roberto Galoppini
 roberto.galopp...@gmail.com wrote:
  2013/7/27 Rob Weir robw...@apache.org
 
  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?

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

2013-07-27 Thread 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

2013-07-27 Thread Roberto Galoppini

2013/7/27 Rob Weir robw...@apache.org

 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?

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

2013-07-27 Thread Rob Weir

On Sat, Jul 27, 2013 at 4:59 PM, Roberto Galoppini
roberto.galopp...@gmail.com wrote:
 2013/7/27 Rob Weir robw...@apache.org

 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.

-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

2013-07-26 Thread 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 hagar.del...@laposte.net 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

2013-07-26 Thread Roberto Galoppini

2013/7/26 Hagar Delest hagar.del...@laposte.net

 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 hagar.del...@laposte.net
 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

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

2013-07-26 Thread 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

2013-07-26 Thread 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?

 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

2013-03-07 Thread Roberto Galoppini

On Mon, Feb 25, 2013 at 4:49 PM, Jürgen Schmidt jogischm...@gmail.com wrote:
 On 2/25/13 4:36 PM, Roberto Galoppini wrote:
 On Thu, Feb 21, 2013 at 2:28 PM, Jürgen Schmidt jogischm...@gmail.com 
 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 extension | grep
 Addons.xcu should be enough. The second step if an
 Addons.xcu is contained is to check for the node
 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.org/node/4979 Monthly: 48
#49

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

2013-03-07 Thread Roberto Galoppini

On Thu, Mar 7, 2013 at 1:36 PM, Herbert Dürr h...@apache.org 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 creative writing in English and
 Hindi)
 #47 http://extensions.services.openoffice.org/node/603

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

2013-02-25 Thread Roberto Galoppini

On Thu, Feb 21, 2013 at 2:28 PM, Jürgen Schmidt jogischm...@gmail.com 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 extension | grep
 Addons.xcu should be enough. The second step if an
 Addons.xcu is contained is to check for the node
 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

2013-02-25 Thread 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 jogischm...@gmail.com 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 extension | grep
 Addons.xcu should be enough. The second step if an
 Addons.xcu is contained is to check for the node
 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

2013-02-21 Thread 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 jogischm...@gmail.comwrote:

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 extension | grep Addons.xcu should be
enough. The second step if an Addons.xcu is contained is to check for
the node oor:name=OfficeToolBar 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

2013-02-21 Thread 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 extension | grep Addons.xcu should be
  enough. The second step if an Addons.xcu is contained is to check for
  the node 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).

 
  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

2013-02-21 Thread 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

2013-02-21 Thread 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 extension | grep
 Addons.xcu should be enough. The second step if an
 Addons.xcu is contained is to check for the node
 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

2013-02-20 Thread Roberto Galoppini

On Mon, Feb 18, 2013 at 8:41 AM, Jürgen Schmidt jogischm...@gmail.comwrote:

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.

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)?

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
?

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.

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

2013-02-17 Thread 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.

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?

Regards,
Andrea.

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

2013-02-17 Thread Fernando Cassia

On Mon, Feb 11, 2013 at 6:46 PM, Rob Weir robw...@apache.org 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

2013-02-17 Thread 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.

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)?

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
?

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.

Juergen

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

2013-02-12 Thread 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

2013-02-12 Thread Jürgen Schmidt

On 2/12/13 12:41 AM, Rob Weir wrote:
 On Mon, Feb 11, 2013 at 5:37 PM, Hagar Delest hagar.del...@laposte.net 
 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

2013-02-12 Thread 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

2013-02-12 Thread 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 jogischm...@gmail.com 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=101t=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

2013-02-12 Thread 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

2013-02-12 Thread 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

2013-02-12 Thread Rob Weir

On Tue, Feb 12, 2013 at 5:31 PM, Hagar Delest hagar.del...@laposte.net 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

4.0 and loss of backward compatibility for extensions with toolbar

2013-02-11 Thread Hagar Delest


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

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?

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.

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?

Hagar

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

2013-02-11 Thread Rob Weir

On Mon, Feb 11, 2013 at 4:10 PM, Hagar Delest hagar.del...@laposte.net 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

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

2013-02-11 Thread 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

2013-02-11 Thread Rob Weir

On Mon, Feb 11, 2013 at 6:03 PM, Andrea Pescetti pesce...@apache.org 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.

37 matches

Mail list logo