Juergen, My comments below. Thanks! - Simon
2012/7/11 Jürgen Schmidt <jogischm...@googlemail.com> > On 7/11/12 8:53 AM, Yong Lin Ma wrote: > > 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. > > that means a 6 month cycle for <minor> releases, correct? > Yes, I think there should be no less than 6 month cycle for <minor> release. > > > > > 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. > > +1 > also +1 > 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. > > I am not sure and it depends on what goes in a 3.5. > > Well I see the benefit of an LTS version and the question is if we want > support such a version for 2 years to give especially enterprise > customers the ability to rely on our software. > As an open source project, I think the LTS can be more driven by customer requirements. If many users stay in one release, and want some critical defects to be fixes, but do not want to upgrade to the next major/minor release, then we should consider to continue to maintain it. It is not mandatory to have the micro release every 3 months if there is no critical defects. e.g. let's create the 3.4.2 release project wiki, but if there is no input for the critical fixes should be in 3.4.2, we can consider to either postpone it, or cancel it if the next major/minor release is coming. While, to run it well, we should ensure the smooth channel to get customer feedback/requirements. > > Yes we are open source but we also want to be professional and we would > like to see that our software is reliable and can be used in > professional environments. > > Hopefully such users/customers can join the project and can help us to > define these requirements better. If not I agree to you and we should > keep the effort to maintain such a release low or shouldn't support it > at all. That means it really depends on the active participation of > customers with such requirements here in the project ;-) > > Juergen > > > > > 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 > > <jogischm...@googlemail.com> wrote: > >> 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. > >>>> > >>> > >>> > >>> > >> > >> > > >
