Ugh.. what I replied here was more pertinent to the
Symphony and AOO thread, sorry.

One thing that we must consider in the future for
is being able to download incremental releases with
binary diffs (like bsdiff). that would make it much
easier to upgrade between micro releases.

Pedro.

--- Mer 11/7/12, Pedro Giffuni <p...@apache.org> ha scritto:
> Hi Andrea;
> 
> --- Mer 11/7/12, Andrea Pescetti <pesce...@apache.org>
> ha scritto:
> ...
> 
> > 
> > Speaking with (too) little knowledge of the effort
> involved,
> > I would keep a 3.4.x series with periodic bugfix
> releases,
> > but use the trunk directly for a 4.0 release including
> the
> > UI changes from Symphony and the other improvements. I
> don't
> > see reasons for an intermediate 3.5 version unless the
> > effort to reach 4.0 requires too long (say, one year).
> >
> 
> I am not an expert, but IMHO ...
> 
> There are some lower hanging fruit: the ICU update, MSXML
> improvements and VBA among others, that can probably be
> easier but the nice things like the accessibility and
> the new UI will take a lot more time. 
> 
> I can't really quantify times but adding all the Symphony
> features into AOO would likely take more that a year and
> can only be done properly by the IBM china guys (and we
> are really lucky to them here).
>  
> > Working towards version 4.0 will bring even more
> interest
> > towards the project and, since the changes would be
> many and
> > substantial, branding the release as 4.0 would be
> totally
> > justified.
> > 
> 
> I certainly think we should target having the Symphony
> UI in the future, and it does seem to fit better new
> platforms like Windows 8, but it is really difficult
> to know off-hand how our existing users will take it.
> 
> At this time there is a huge inertia building around
> Option I but I don't think we should close the doors
> completely to option II.
> 
> I would like to hear more from our long-time
> developers on which approach they like best,
> but perhaps it's not yet a good time to take
> a decision.
> 
> Pedro.
>

Reply via email to