On Tue, Jul 10, 2012 at 11:13 PM, Jürgen Schmidt <[email protected] > wrote:
> On 7/10/12 11:30 PM, Kay Schenk wrote: > > On Tue, Jul 10, 2012 at 9:43 AM, Pedro Giffuni <[email protected]> wrote: > > > >> Just my $0.02 > >> > >> --- Mar 10/7/12, Rob Weir <[email protected]> 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
