On 7/10/12 11:30 PM, Kay Schenk wrote: > On Tue, Jul 10, 2012 at 9:43 AM, Pedro Giffuni <p...@apache.org> wrote: > >> Just my $0.02 >> >> --- Mar 10/7/12, Rob Weir <robw...@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. >> > > >
