incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: After AOO 3.4?
Date Sun, 29 Apr 2012 00:30:23 GMT
On Sat, Apr 28, 2012 at 4:07 PM, Pedro Giffuni <pfg@apache.org> wrote:
> Hello;
>
>
> On 04/28/12 11:32, Rob Weir wrote:
>>
>> I'm already starting to get questions on what we'll be doing after AOO
>> 3.4 is released.  Based on previous conversations on this list, I'm
>> able to speak confidently about a few things:
>>
>> 1) We'll probably graduate to a Top Level Project
>>
>> 2) IBM says they will contribute Symphony source code after 3.4 is
>> released
>>
>> 3) We have some initial feature ideas for AOO 4.0 on the wiki:
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning
>>
>> 4) We also have some ideas listed for an AOO 4.1:
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Feature+Planning
>>
>> Beyond that, do we have anything to say?
>
>
> Well, we have to integrate some CWSs. I am interested in gnumake4
> since it might help clean some issues in the BSD port. For the rest
> I am not sure what is there or how stable it is so I would guess
> we should tackle them slowly and leave most of them for "later".
>
> We also have to update some components. Anything with an Apache
> tag on it, like Apache Commons or Apache Lucene comes first
> because working with other Apache projects is key for our
> graduation. Some other components are important but involve a lot
> of hard work: It would be really great if someone from ICU would
> give a hand too.
>
> The clang port is also rather important and would help the MacOSX
> support.
>
> Finally, I think we should continue cleaning/replacing some Category-B
> software. For example, carrying an outdated version of Mozilla SeaMonkey
> just for addressbook support, is a nonsense.
>
> All in all, I think we should focus on stability and not on features.
>

So these (to me) sound more like items for a 3.5 than a 3.4.1.

Here's how I see things, based on my experience with commercial
software development:

1) We want to have a maintenance branch that can be used to deliver
quick-turnaround releases.  This would be in case we receive reports
of a security vulnerability, or a new critical bug, or maybe something
that breaks in us due to a platform update.  In other words, things we
need to react to quickly.

In order to turn around a maintenance release quickly we need to limit
changes.  We don't have betas for these releases.  We might require
code reviews.   We test changes and "test around" changes, but we
might not have a full test cycle.   The documentation does not change.

We might make very limited feature additions, if they can be made
without requiring core code changes.  For example, adding a new
language is general safe, since the test effort is limited to that
language.  You cannot break existing 3.4 functionality by adding a new
language.

2) We also want feature release, like 3.5, 3.6, etc.  Almost anything
can go into them.  They might have beta release.  They would have full
test cycles.  They would require all translations to be updated.
Documentation would need to be updated as well.

3) Then we have major updates, like 4.0.  These are similar to #2,
only more substantial.

Was there a similar distinction made in OOo?

-Rob

> Just my $0.02.
>
> Pedro.
>

Mime
View raw message