On Sat, Feb 9, 2013 at 1:17 PM, janI <j...@apache.org> wrote: > ---------- Forwarded message ---------- > From: janI <j...@apache.org> > Date: 9 February 2013 19:17 > Subject: Re: Changes that Impact Backwards Compatibility > To: janI <j...@apache.org> > > > Stupid browser .... sorry for that. > > > > On 9 February 2013 19:15, janI <j...@apache.org> wrote: > >> Hi. >> >> When do you expect a feature to enter the list. >> 1) Before development >> 2) Before committing to trunk (e.g. committed in a branch) >> 3) after QA. >>
It is not to track AOO 4.0 stuff that "might happen". So I wouldn't put items in their before development happens. But I'd put items in there after the code is checked in. -- this can be a guide for QA to know what areas to concentrate on -- It tells doc what new items to document -- We could have a blog post drawing attention to changes in API's that extension authors and others should be aware of, so they have time to update their apps. Note: we can easily produce a report before AOO 4.0 is released, looking at Bugzilla and Subversion logs, to get a list of bugs fixed, etc. But it is better IMHO to get the important items written down as soon as they happen, so we can better coordinate. -Rob >> The reason for my question, is that I work on l10n tools, which I hope >> will make it to 4.0, The tools have a high effect on the translation >> process: >> a) the sdf files will no longer exist >> b) there will only be 2x45 files >> > c) help and ui will not be seperate projects. > > The first part is available in branch l10n but not integrated in build, or > tested yet. > > Rgds > Jan I. > > >> >> >> On 9 February 2013 18:40, Rob Weir <robw...@apache.org> wrote: >> >>> I've added a new section to the 4.0 Release Notes for tracking changes >>> that impact backwards compatibility: >>> >>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes >>> >>> This would include changes to the public interfaces of AOO, including >>> incompatible changes to API's (including spreadsheet functions), file >>> formats, etc. >>> >>> I think we all acknowledge that a major release like 4.0 is an >>> opportunity to make incompatible changes, but I hope we also agree >>> that this is not a free-for-all where we can indiscriminately break >>> compatibility. We need to think carefully about where we break >>> compatibility, have good reasons for it, and have a plan for how we >>> communicate such changes to users and application developers. The >>> later, especially, need advance notice. >>> >>> Personally, I consider any changes that break compatibility to be >>> "controversial" and think that lazy consensus should be sought on this >>> list before committing it. >>> >>> Regards, >>> >>> -Rob >>> >> >>
