From api-return-180-apmail-openoffice-api-archive=openoffice.apache.org@openoffice.apache.org Thu Jan 17 15:03:02 2013 Return-Path: X-Original-To: apmail-openoffice-api-archive@www.apache.org Delivered-To: apmail-openoffice-api-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AEE47E276 for ; Thu, 17 Jan 2013 15:03:02 +0000 (UTC) Received: (qmail 30155 invoked by uid 500); 17 Jan 2013 15:03:02 -0000 Delivered-To: apmail-openoffice-api-archive@openoffice.apache.org Received: (qmail 30055 invoked by uid 500); 17 Jan 2013 15:03:02 -0000 Mailing-List: contact api-help@openoffice.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: api@openoffice.apache.org Delivered-To: mailing list api@openoffice.apache.org Received: (qmail 30031 invoked by uid 99); 17 Jan 2013 15:03:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Jan 2013 15:03:01 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jogischmidt@gmail.com designates 209.85.215.43 as permitted sender) Received: from [209.85.215.43] (HELO mail-la0-f43.google.com) (209.85.215.43) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Jan 2013 15:02:51 +0000 Received: by mail-la0-f43.google.com with SMTP id eg20so2767440lab.16 for ; Thu, 17 Jan 2013 07:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=ynAwvBGNycA29C5OXSSISzUIg5eahs1+DPr/bRThzgA=; b=xhXFTjQ+NzTeI3vnr2P4PaR/B4jP/ac1P5tjXuLsX3yYnVbwiPlfABXPeanovlAFag 1r6TzceIc3yf5feKuVuYmP971HZYfz6DqzAx+c81qxc9QQqXF84CCxoJsOElMadh6IWx OyIp0FPFfr+7pLSX3rlf3JzxOSuaGTj8zA499+oeW4a73g5Kzs+LvXLh9+Zq0DVPQjF7 hHkuUxVWVt6fLwbzdSPaXVYImecTLgRbKTQojqz96y0eBIqWEL94+VeDbmGMnzehsAFe H4D8JhTJXip6PvlI25mf+H2ts5DL1dits2juGVQkfn1w7+ZaF21tpE5FxDaEkr/J+XKK cUDQ== X-Received: by 10.152.114.66 with SMTP id je2mr5091358lab.40.1358434950899; Thu, 17 Jan 2013 07:02:30 -0800 (PST) Received: from [9.155.131.125] (deibp9eh1--blueice2n2.emea.ibm.com. [195.212.29.172]) by mx.google.com with ESMTPS id ft8sm841644lab.9.2013.01.17.07.02.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 07:02:29 -0800 (PST) Message-ID: <50F81284.7030903@gmail.com> Date: Thu, 17 Jan 2013 16:02:28 +0100 From: =?ISO-8859-1?Q?J=FCrgen_Schmidt?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: api@openoffice.apache.org Subject: Re: Incompatible change for extensions References: <50F7DF5F.6090700@club-internet.fr> <50F7EC5F.9040309@gmail.com> <50F8040B.8030003@club-internet.fr> In-Reply-To: <50F8040B.8030003@club-internet.fr> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 1/17/13 3:00 PM, Bernard Marcelly wrote: > Message de Jürgen Schmidt date 2013-01-17 13:19 : >> >> I disagree, the old mechanism is a design bug and should be resolved. It >> was always planned to fix this a major release. Now with 4.0 we can make >> such changes and we had long discussions about incompatible changes for >> major releases. Extensions can be easy updated and by the way it is >> always a good idea to add a max version dependency and release a new >> version of your extension if you have ensured that it works with the >> newest office version. How many unpublished API's are used in extensions >> that can change at any time? >> >> We probably don't have enough time to fix many more design bugs in the >> API for 4.0 but this one is definitely worth the change. We will >> document it and the fix is easy. But for all new extensions the usage is >> much more intuitive and less error prone. >> > > The current mechanism is not a design bug (because it works), rather a > clumsy design. > > To create a toolbar with the same name in Calc, Draw, Impress, you have to: > - create one WindowState xcu file > - make 2 copies of this file > - modify one line in each copy > - add entries for these files in the manifest.xml > Is this really complex, error prone ? I don't think so, compared to all > other features of an extension. > > About max version dependency : application developers don't see the > future. It's not possible to know in advance when (and why) an extension > will become incompatible. exactly and that is the reason why I would today add a max version dependency always. I know 4.0 will be next, I would change the max version dependency to 4.0 after testing that everything works and would do a micro release if I change nothing else. > > In the context of a company that has created a specific extension, > happily used for years, Apache OpenOffice 4.0 will be a bad surprise. > Releasing a new version will be difficult: the original developer may > have gone, or have forgotten the building details of an extension; a new > developer has to learn the syntax of an oxt file, and find out what has > to be changed to make it work again. Costs, delays. Benefits ? None. This would be a situation that is always bad. If you use unmaintained code you can run always in such trouble. In this specific case the oxt can be changed easily and the Addon.xcu can be adapted, repackage the oxt and that's it. No real code changes and you don't have to remove any XXXWindowState.xcu if you have one. I would love to have much more time to fix API design bugs or change some bad API's to make the life for developers easier in the future. I was a big fan of compatible API's but learned over time that good API's have to evolve over time. We didn't do that and the API is often not easy to use and to understand in many areas. We can improve a lot here but probably not compatible. I have a mixed feeling about it but believe that it will help us to make the product better over time. This is an easy change, other API changes that require real code changes will be more difficult to communicate. As long as we communicate and document these kind of changes and provide migration paths we are on a good way I think. We have to look forward. Juergen