incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yong Lin Ma <mayo...@apache.org>
Subject Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Date Wed, 11 Jul 2012 06:53:06 GMT
This is a good topic.

I prefer to having 2 major releases every year, like 3.x or 4.x.  and
there can be maintain releases like 3.x.x between major releases for
fixes of critical issues.

TLS is an valid idea. But we should not do that until we see tangible
requirments from users and we have enough contributors for that.  By
far, we should encourge users to upgrade to next major release.  For
example, we would not provide new 3.4.x release after 3.5 is out,
although that would be good for certain users. But not quite practical
for us.

Release after 3.5 can be named as 3.6 or 4.0, purely depends on how
many improvement we can make in it. It doesn't matter where the
improvments come from.


On Wed, Jul 11, 2012 at 2:13 PM, J├╝rgen Schmidt
<jogischmidt@googlemail.com> wrote:
> On 7/10/12 11:30 PM, Kay Schenk wrote:
>> On Tue, Jul 10, 2012 at 9:43 AM, Pedro Giffuni <pfg@apache.org> wrote:
>>
>>> Just my $0.02
>>>
>>> --- Mar 10/7/12, Rob Weir <robweir@apache.org> 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
>
> <major>.<minor>.<micro>
>
> <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
>
> Juergen
>
>
>>
>>
>>
>>>
>>> 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.
>>>
>>
>>
>>
>
>

Mime
View raw message