openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <>
Subject Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Date Wed, 11 Jul 2012 06:13:48 GMT
On 7/10/12 11:30 PM, Kay Schenk wrote:
> On Tue, Jul 10, 2012 at 9:43 AM, Pedro Giffuni <> wrote:
>> Just my $0.02
>> --- Mar 10/7/12, Rob Weir <> ha scritto:
>>> But of course the open source ethos is "release early;
>>> release often".
>>>  So we need some way to balance that as well.
>> I don't think that would play well for this project. It
>> has certainly been bad for other projects already. We
>> don't want to put out experimental releases. People pretty
>> just much want an Office suite that does what AOO does now
>> but is bug free.
> I agree with Pedro here. I'm not sure it would be a good idea to put
> "stress" on the project this way, though I DO think that some ongoing
> "feasibility planning" for regular releases might be a good idea.

I think the point Simon wanted to address is the general approach we
would like to follow in the future. Means some kind of release model.
And I think that is a very important thing and we should find a common
agreement on how we an to move forward. This is independent of any
Symphony feature/fix integration code merging work.

The point from Rob for a LTS release is of course really valid and
important as well. Companies don't switch their deployments often and
don't take all minor releases.

General versioning scheme


<micro> = only critical bug and security fixes
<minor> = <micro> + smaller enhancement, improvements, new features
without bigger UI changes. Smaller UI changes are of course possible.
<major> = <minor> + everything else but with a good planning and
communication to include documentation, marketing etc.

A 3-4 month cycle for <micro> releases seems to be reasonable and I
would like to try it. We will see and learn over time if it is too time
consuming or if we can manage it. And of course we have to be flexible
if critical security fixes come up.

6 or 12 month cycle for <minor> releases is both ok for me. 6 is better
from a community perspective to include contributions from new
developers as soon as possible.

And <major> releases depends on the ideas and changes we want to make in
the future. I would not say that we have to make a major release every 2
years or so, it really depends on the content.  But of course a 2 year
cycle sounds good and gives us enough opportunity to push some marketing
activities around it.

>> I would prefer if we focus on two levels:
>> 3.5 Release including all the low hanging fruit: updates
>> to ICU and Python better support for MS format, VBA.
> I've been wondering about a possible "3.5" release myself. Juergen and
> others have mentioned *it*, but we don't seem to have a document for it on
> the planning wiki.

talking about it was quite easy because it was simply a + 0.1 ;-) I am
happy that Simon brought it up now. We should create a 3.5 wiki page and
I will do it later today that we can start the planning.

In a 3.5 we can integrate many fixes and fidelity improvements from
Symphony as Simon pointed out without bigger UI changes but of huge
value for customers who have to work deal with MS formats etc. And of
course we will increase the quality.
And we can of course and I hope we will include some other new things
not from Symphony as well. That means developers can start to add their
new stuff as well. Just propose it and do it! And of course discuss it
if potential concerns come up ;-)

> Maybe we could skip a 3.4.2. release if we feel so inclined and include any
> additional bug fixes in 3.5 with your suggestions here. At any rate, maybe
> someone could start a 3.5 doc on the planning wiki. Maybe shoot for end of
> normal 3rdQ?

That would be possible but taking the LTS idea into account I would
prefer a 3.4.2 with only critical bug and security fixes. And a 3.5 as
proposed in Q1/2013.

That is just my opinion


>> 4.0 Release - Merging Symphony and perhaps adding some
>> new features.
> yes...
>> We can work on them sequentially (first 3.5 then 4.0) or
>> in parallel letting some fruits from 4.0 fall into 3.5
>> when they are stable. No strong opinion.
>> Pedro.

View raw message