incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shenfeng Liu <liush...@gmail.com>
Subject Fwd: [RELEASE] 3.5 project wiki created - Thanks to Juergen!
Date Fri, 13 Jul 2012 03:15:44 GMT
  I noticed that Juergen just created the wiki for AOO 3.5 :
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5
  It will be a good place to consolidate our proposal and discussion.
Thanks, Juergen!

  I didn't aware any formal process here like many companies defined: (1)
propose a release; (2) approve to go; (3) execute on this release... We
just discussed it in this mail thread. So I think if any one disagree with
the release 3.5, just speak out.

  For 3.5, I hope Juergen can continue to be the release manager. And I
volunteer myself to assist Juergen on some project management work,
including maintaining the release wiki.

  We can try to input the proposed contents. Some candidates in my mind:

    - Fidelity enhancements
    - Performance/Reliability improvements
    - ICU update (proposed by Petro)
    - File association (on discussion in another mail thread)
    - Apache branding ?
    - <none product> test framework enhancement
    - <none product> iterative development and milestone builds

  Thanks!

- Simon


---------- Forwarded message ----------
From: Shenfeng Liu <liushenf@gmail.com>
Date: 2012/7/12
Subject: Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
To: ooo-dev@incubator.apache.org, pfg@apache.org


Pedro,
  I think your comments are also very valuable to this planning thread! For
the Symphony value integration, per Symphony team's evaluation, will take 2
years or even longer for all the contents. That's why I think it is
critical to define some release in the middle to fruit. Fidelity,
performance, and other pieces like ICU & VBA that you mentioned, are some
thing important to most of our users, and relatively easy to migrate those
fixes/enhancements from Symphony. UI changes is a more complex topics, not
only from the technical perspective, but also user experience study for the
integration, which I believe will take long time for discussion. So I
suggest releases like 3.5, 3.6 to be on the way to 4.0.

- Simon



2012/7/12 Pedro Giffuni <pfg@apache.org>

> 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 <pfg@apache.org> ha scritto:
> > Hi Andrea;
> >
> > --- Mer 11/7/12, Andrea Pescetti <pescetti@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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message