incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Date Wed, 11 Jul 2012 21:26:05 GMT
On Tue, Jul 10, 2012 at 11: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.
>

This is a nice way of stating this. Thanks.


>
> 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.
>

OK, I see what you're saying. Kind of regardless of the number of "issues,
we try to stick with a 3-4 cycle for "micro" releases. With the
admonishment of critical security flaws. OK, I can see this and even it
only amounted to a few issues to fix, we should do this. It will prevent
AOO from looking stale.


>
> 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.
>

OK, we can shoot for this.


>
> 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.
>

That would be be very helpful.

And, thanks again for your analysis. It really was very helpful to me at
least.


>
> 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.
> >>
> >
> >
> >
>
>
>


-- 
----------------------------------------------------------------------------------------
MzK

"I would rather have a donkey that takes me there
 than a horse that will not fare."
                                          -- Portuguese proverb

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