You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Shenfeng Liu <li...@gmail.com> on 2012/07/10 16:07:33 UTC
[RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Hi, all,
Since we are stepping forward to the 3.4.1 release smoothly, I think
maybe it is time for us to look ahead for our next release now.
I remember we had a discussion previously on how to run AOO's future
releases, time boxed vs content boxed, 3.4.1 vs 3.5 vs 4.0... I think we
should resume this discussion.
IMHO, timely release will give AOO a very good promotion to marketing.
Certainly we can decide the size of the release. We released 3.4 at May 8,
and then will release 3.4.1 after about 3 months. It looks like a very good
rhythm. Maybe we can consider a 3.4.2 in 4Q, 3.5 in 1Q next year...
Another way to consider is the release contents. Checking the feature
requirement list and defect backlog, see what we can make after 3 months or
6 months. Or if there is any thing must be in the next release no matter
how long it will take (e.g. security fix). We partially did this practice
before by collecting the 4.0 requirements in wiki:
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning.
And I remember there was a common interesting at that time that we
should
do an immediate release for critical defect fixes (which is 3.4.1 that we
are doing now), and then a mid-term release which majorly target to
fidelity improvements (3.5), and a long term release with Symphony values
on UX and social integrations (4.0)...
I'm not sure how to do a release proposal. Is that we should create a
project wiki and discuss the release goals, contents, outlook GA date? And
if we agree on this release, we move on. If we do not agree, we abandon it?
I'm asking because I want to propose that:
(1) We should begin to check if any critical defects in our backlog that
require us for a 3.4.2.
(2) We should begin to discuss a bigger release like 3.5 on the release
goals, and proposed contents, and the release number...
Just my 2 cents... Any suggestion/comments?
Thanks!
- Simon
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by "Keith N. McKenna" <ke...@comcast.net>.
Shenfeng Liu wrote:
> Hi, all,
> Since we are stepping forward to the 3.4.1 release smoothly, I think
> maybe it is time for us to look ahead for our next release now.
>
> I remember we had a discussion previously on how to run AOO's future
> releases, time boxed vs content boxed, 3.4.1 vs 3.5 vs 4.0... I think we
> should resume this discussion.
>
> IMHO, timely release will give AOO a very good promotion to marketing.
> Certainly we can decide the size of the release. We released 3.4 at May 8,
> and then will release 3.4.1 after about 3 months. It looks like a very good
> rhythm. Maybe we can consider a 3.4.2 in 4Q, 3.5 in 1Q next year...
>
> Another way to consider is the release contents. Checking the feature
> requirement list and defect backlog, see what we can make after 3 months or
> 6 months. Or if there is any thing must be in the next release no matter
> how long it will take (e.g. security fix). We partially did this practice
> before by collecting the 4.0 requirements in wiki:
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning.
> And I remember there was a common interesting at that time that we
> should
> do an immediate release for critical defect fixes (which is 3.4.1 that we
> are doing now), and then a mid-term release which majorly target to
> fidelity improvements (3.5), and a long term release with Symphony values
> on UX and social integrations (4.0)...
>
> I'm not sure how to do a release proposal. Is that we should create a
> project wiki and discuss the release goals, contents, outlook GA date? And
> if we agree on this release, we move on. If we do not agree, we abandon it?
>
> I'm asking because I want to propose that:
>
> (1) We should begin to check if any critical defects in our backlog that
> require us for a 3.4.2.
>
> (2) We should begin to discuss a bigger release like 3.5 on the release
> goals, and proposed contents, and the release number...
>
> Just my 2 cents... Any suggestion/comments?
>
> Thanks!
>
> - Simon
>
Simon;
This sounds to me like a very good idea. Getting to a reasonably
predictable release schedule will only enhance the fact to the
marketplace that AOO is a vital project dedicated to the reputation of
quality that OpenOffice.org worked so hard to achieve. The best way to
achieve that I believe, is to have robust planning discussions involving
all areas of the project.
Regards
Keith
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Hagar Delest <ha...@laposte.net>.
Generally agreeing. So top posting.
The problem I see with LTS is that it leads to additional energy put on old releases. In the past, the only choice was to upgrade. Or not, and wait for a release with the blocking bug fixed (in case it prevented the upgrade). It kept the development focusing on the next release.
Perhaps the first thing to implement is the possibility of fixes by patches so that maintenance of former versions can be dealt without much energy. See the OOo 3.3 issue with ODF documents: it could have been fixed by a mere patch I guess (but I'm no developer).
What could be a good "marketing" move is to have a (not so) minor version (before 4.0) that focuses on a bug fix major campaign. There are many popular bugs (with many votes) still alive. Since the code has been partly cleaned during the IP clearance, what about having a [new] look at all those bugs? I think that as users, we are more concerned by existing bugs than waiting for new features. I recall for example the 65k characters limit for paragraphs that is a show blocker for many lawyers in US (some of their documents have to be a single paragraph it seems).
Once we start using AOO, a missing feature is hardly a show stopper (or in such case, it's checked at a first and AOO is then removed immediately, there won't be any feedback, the user won't bother to do it after a first installation).
But bugs are really obstacles to productivity and not working on them leads to frustration for the users and demonstrates poor consideration for users.
Hagar
Le mer. 11 juil. 2012 13:51:01 CEST, Wolf Halton <wo...@gmail.com> a écrit :
> On Wed, Jul 11, 2012 at 7:20 AM, Regina Henschel <rb...@t-online.de>wrote:
>
>> Hi all,
>>
>> Shenfeng Liu schrieb:
>>
>> Hi, all,
>>> Since we are stepping forward to the 3.4.1 release smoothly, I think
>>> maybe it is time for us to look ahead for our next release now.
>>>
>>> I remember we had a discussion previously on how to run AOO's future
>>> releases, time boxed vs content boxed, 3.4.1 vs 3.5 vs 4.0... I think we
>>> should resume this discussion.
>>>
>>> IMHO, timely release will give AOO a very good promotion to marketing.
>>> Certainly we can decide the size of the release. We released 3.4 at May 8,
>>> and then will release 3.4.1 after about 3 months. It looks like a very
>>> good
>>> rhythm. Maybe we can consider a 3.4.2 in 4Q, 3.5 in 1Q next year...
>>>
>>> Another way to consider is the release contents. Checking the feature
>>> requirement list and defect backlog, see what we can make after 3 months
>>> or
>>> 6 months. Or if there is any thing must be in the next release no matter
>>> how long it will take (e.g. security fix). We partially did this practice
>>> before by collecting the 4.0 requirements in wiki:
>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>> AOO+4.0+Feature+Planning<https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning>
>>> .
>>> And I remember there was a common interesting at that time that we
>>> should
>>> do an immediate release for critical defect fixes (which is 3.4.1 that we
>>> are doing now), and then a mid-term release which majorly target to
>>> fidelity improvements (3.5), and a long term release with Symphony values
>>> on UX and social integrations (4.0)...
>>>
>>> I'm not sure how to do a release proposal. Is that we should create a
>>> project wiki and discuss the release goals, contents, outlook GA date? And
>>> if we agree on this release, we move on. If we do not agree, we abandon
>>> it?
>>>
>>> I'm asking because I want to propose that:
>>>
>>> (1) We should begin to check if any critical defects in our backlog that
>>> require us for a 3.4.2.
>>>
>>> (2) We should begin to discuss a bigger release like 3.5 on the release
>>> goals, and proposed contents, and the release number...
>>>
>>> Just my 2 cents... Any suggestion/comments?
>>>
>>
>> I thought it might be useful to look in the history and have extracted
>> some dates from http://ftp-1.gwdg.de/pub/**openoffice/archive/stable/<http://ftp-1.gwdg.de/pub/openoffice/archive/stable/>
>>
>> OOo 1.0.2 2003-03-14
>> OOo 1.0.3 2003-04-18
>> OOo 1.1.0 2003-10-14
>> OOo 1.1.4secpatch 2005-04-12
>> OOo 1.1.5 2005-09-04
>> OOo 1.1.5secpatch 2006-07-04
>> OOo 1.1.5secpatch2 2006-12-22
>> OOo 2.1.0 2006-12-14
>> OOo 2.2.0 2007-03-22
>> OOo 2.2.1 2007-06-04
>> OOo 2.3.0 2007-07-14
>> OOo 2.3.1 2007-11-15
>> OOo 2.4.0 2008-03-16
>> OOo 2.4.1 2008-05-30
>> OOo 2.4.2 2008-10-27
>> OOo 2.4.3 2009-08-24
>> OOo 3.0.0 2008-10-06
>> OOo 3.0.1 2009-01-26
>> OOo 3.1.0 2009-05-04
>> OOo 3.1.1 2009-08-20
>> OOo 3.2.0 2010-02-03
>> OOo 3.2.1 2010-05-26
>> OOo 3.3.0 2011-01-18
>> OOo 3.4beta 2011-04-07
>>
>> We had the first <micro>-release after around 3 month. The next ones when
>> needed, with support of the last <minor>-release up to 1 year 3 month.
>>
>> We had <minor>-releases all 9 month (around) and <major>-release 3 years 9
>> months from OOo1 to OOo2 and 1 year 10 months form OOo2 to OOo3.
>>
>> We have to consider, that the development is no longer enterprise driven
>> and that there are less translators as before.
>>
>> Kind regards
>> Regina
>>
>
> As an enterprise-software user, I am happy not to have major releases come
> too fast. The software I mostly consume, however is operating systems and
> web apps. My opinion here may be of less value than those of people who
> support the end-users of office suites.
>
> LTS versions that are upgradeable without having to resort to installing
> the intervening versions seem valid and useful to me, and I would like the
> major versions to keep a three to five year interval. Exact interval is not
> all that important to me, I am a Debian Admin, after all. The longer the
> interval and EOL, the happier the support technicians, IMO. Microsoft
> Windows XP was production stable for 11 years and will not go out of
> support for several more years, which allowed for a very stable platform
> for development.
>
> Individual users like features and "improvements" in UX. They are the ones
> who are upgrading whenever a point upgrade. I am one of these for my
> personal choice of office suite. I like auto-suggestions from my software
> telling me there is an update of any kind, and I usually install all
> releases if they are auto-suggested. The Firefox release schedule is only
> annoying because their plugin developers cannot keep up.
>
> As another idea for a policy for release designation:
> Bug-fix updates are point updates where the changing number is the third
> section:: 3.4.0 to 3.4.1 to 3.4.2 etc.
> Feature upgrades are minor updates and the second digit increments.
> Wherever we are in the bugfix and security release numbering 3.4.17 would
> next go to 3.5.0 and the next security and bugfix update would be 3.5.1.
> Major refactorings (or perhaps the LTS release) would increment the first
> digit. Wherever we are in the feature and bugfix updates we would jump
> from, say, 3.5.4 to 4.0.0.
>
> Cheers,
> Wolf
>
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Shenfeng Liu <li...@gmail.com>.
Hi, Rob,
My comments below.
- Simon
2012/7/11 Rob Weir <ro...@apache.org>
> On Wed, Jul 11, 2012 at 7:51 AM, Wolf Halton <wo...@gmail.com>
> wrote:
> > On Wed, Jul 11, 2012 at 7:20 AM, Regina Henschel <
> rb.henschel@t-online.de>wrote:
> >
> >> Hi all,
> >>
> >> Shenfeng Liu schrieb:
> >>
> >> Hi, all,
> >>> Since we are stepping forward to the 3.4.1 release smoothly, I think
> >>> maybe it is time for us to look ahead for our next release now.
> >>>
> >>> I remember we had a discussion previously on how to run AOO's future
> >>> releases, time boxed vs content boxed, 3.4.1 vs 3.5 vs 4.0... I think
> we
> >>> should resume this discussion.
> >>>
> >>> IMHO, timely release will give AOO a very good promotion to
> marketing.
> >>> Certainly we can decide the size of the release. We released 3.4 at
> May 8,
> >>> and then will release 3.4.1 after about 3 months. It looks like a very
> >>> good
> >>> rhythm. Maybe we can consider a 3.4.2 in 4Q, 3.5 in 1Q next year...
> >>>
> >>> Another way to consider is the release contents. Checking the
> feature
> >>> requirement list and defect backlog, see what we can make after 3
> months
> >>> or
> >>> 6 months. Or if there is any thing must be in the next release no
> matter
> >>> how long it will take (e.g. security fix). We partially did this
> practice
> >>> before by collecting the 4.0 requirements in wiki:
> >>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
> >>> AOO+4.0+Feature+Planning<
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning
> >
> >>> .
> >>> And I remember there was a common interesting at that time that we
> >>> should
> >>> do an immediate release for critical defect fixes (which is 3.4.1 that
> we
> >>> are doing now), and then a mid-term release which majorly target to
> >>> fidelity improvements (3.5), and a long term release with Symphony
> values
> >>> on UX and social integrations (4.0)...
> >>>
> >>> I'm not sure how to do a release proposal. Is that we should create
> a
> >>> project wiki and discuss the release goals, contents, outlook GA date?
> And
> >>> if we agree on this release, we move on. If we do not agree, we abandon
> >>> it?
> >>>
> >>> I'm asking because I want to propose that:
> >>>
> >>> (1) We should begin to check if any critical defects in our backlog
> that
> >>> require us for a 3.4.2.
> >>>
> >>> (2) We should begin to discuss a bigger release like 3.5 on the release
> >>> goals, and proposed contents, and the release number...
> >>>
> >>> Just my 2 cents... Any suggestion/comments?
> >>>
> >>
> >> I thought it might be useful to look in the history and have extracted
> >> some dates from http://ftp-1.gwdg.de/pub/**openoffice/archive/stable/<
> http://ftp-1.gwdg.de/pub/openoffice/archive/stable/>
> >>
> >> OOo 1.0.2 2003-03-14
> >> OOo 1.0.3 2003-04-18
> >> OOo 1.1.0 2003-10-14
> >> OOo 1.1.4secpatch 2005-04-12
> >> OOo 1.1.5 2005-09-04
> >> OOo 1.1.5secpatch 2006-07-04
> >> OOo 1.1.5secpatch2 2006-12-22
> >> OOo 2.1.0 2006-12-14
> >> OOo 2.2.0 2007-03-22
> >> OOo 2.2.1 2007-06-04
> >> OOo 2.3.0 2007-07-14
> >> OOo 2.3.1 2007-11-15
> >> OOo 2.4.0 2008-03-16
> >> OOo 2.4.1 2008-05-30
> >> OOo 2.4.2 2008-10-27
> >> OOo 2.4.3 2009-08-24
> >> OOo 3.0.0 2008-10-06
> >> OOo 3.0.1 2009-01-26
> >> OOo 3.1.0 2009-05-04
> >> OOo 3.1.1 2009-08-20
> >> OOo 3.2.0 2010-02-03
> >> OOo 3.2.1 2010-05-26
> >> OOo 3.3.0 2011-01-18
> >> OOo 3.4beta 2011-04-07
> >>
> >> We had the first <micro>-release after around 3 month. The next ones
> when
> >> needed, with support of the last <minor>-release up to 1 year 3 month.
> >>
> >> We had <minor>-releases all 9 month (around) and <major>-release 3
> years 9
> >> months from OOo1 to OOo2 and 1 year 10 months form OOo2 to OOo3.
> >>
> >> We have to consider, that the development is no longer enterprise driven
> >> and that there are less translators as before.
> >>
> >> Kind regards
> >> Regina
> >>
> >
> > As an enterprise-software user, I am happy not to have major releases
> come
> > too fast. The software I mostly consume, however is operating systems
> and
> > web apps. My opinion here may be of less value than those of people who
> > support the end-users of office suites.
> >
> > LTS versions that are upgradeable without having to resort to installing
> > the intervening versions seem valid and useful to me, and I would like
> the
> > major versions to keep a three to five year interval. Exact interval is
> not
> > all that important to me, I am a Debian Admin, after all. The longer the
> > interval and EOL, the happier the support technicians, IMO. Microsoft
> > Windows XP was production stable for 11 years and will not go out of
> > support for several more years, which allowed for a very stable platform
> > for development.
> >
>
> +1. This is a common enterprise requirement.
>
> One perspective on this is here:
>
> http://www.computerworld.com/s/article/9217896/Enterprise_IT_unhappy_with_Firefox_4_s_quick_demise
>
> But we should go back to what is actually valuable about 'release
> early, release often'. It is not about the formality of an
> Apache-style release. The real importance is:
>
> 1) Developers not hoarding code until the last minute. Integrating
> code earlier is better for stability
>
> 2) Allowing QA team to test earlier
>
> 3) Allow the community to see new features earlier, and offer feedback
> earlier
>
> 4) The increase in energy and enthusiasm that comes when we show
> regular progress to ourselves and the world
>
> If there are lightweight ways of accomplishing this, then we should
> prefer those over a full Apache release. For example, dev snapshots,
> perhaps more regularly build with desktop integration, would enable
> all of this. Having them built directly from the Buildbot would be
> idea, Then we would just need to develop a convention, like 'dev
> snapshots builds will always be those made on Sunday at 1200 UTC.
> Avoid risky check-ins close to that build".
>
+1
And I will suggest we try the iteration development mode. e.g. 4 weeks per
iteration. And we can deliver a milestone build after each iteration, which
contains certain number of completed feature/enhancements and bug fixes,
and relatively stable (verified through the iteration regression test). The
milestone builds are not formal release builds, but can be used for early
try out of the new features, and get quality feedback.
>
> As for Micro-releases, and minor releases, imagine it is a year from
> now and we have made the following release:
>
> 3.4.0
> 3.4.1
> 3.4.2
> 3.5.0
> 3.5.1
> 3.6.0
>
> Now a critical bug comes up, perhaps a report of a security
> vulnerability. Where do we fix it?
>
> 1) If we only fix it in 3.6.1 then we will be forcing everyone to
> upgrade to a new feature level, with new bugs, incompatibility,
> conversion issues, etc.
>
> 2) If we fix everywhere (3.4.3, 3.5.2 and 3.6.1) then this is very
> labor intensive for us. And what do we do after two years? This
> quickly explodes.
>
> 3) However, if we set expectations that only certainly release are
> LTS, then we only need to patch the current release and the LTS
> release. For example if 3.4.0 was declared LTS, then we would release
> a 3.4.3 and a 3.6.1. And even if two years had passed, and we had
> 3.7, 3.8, we would still only worry about the current build and the
> LTS build(s).
>
> That's why I think it is important to set expectation on this now, so
> users know which track to get on, which upgrades to make, etc.
>
IMHO, it sounds good, but the problem might be how to define the release
for LTS.
My thought is, we should define only 1 under every major release for LTS
(e.g. 1 in 3.x, and 1 in 4.x). Since there will not be much changes on UI
or infrastructure between minor releases, the cost of upgrade should be
sustainable. It is likely to have a quality verification for the function
areas you or your company/organization interested before the upgrade.
If it is the situation, then the LTS should be to the major release level.
e.g. for version 3, LTS means the latest 3.x or 3.x.y, same to version 4.
So that our development effort can be saved also.
>
> -Rob
>
> > Individual users like features and "improvements" in UX. They are the
> ones
> > who are upgrading whenever a point upgrade. I am one of these for my
> > personal choice of office suite. I like auto-suggestions from my
> software
> > telling me there is an update of any kind, and I usually install all
> > releases if they are auto-suggested. The Firefox release schedule is
> only
> > annoying because their plugin developers cannot keep up.
> >
> > As another idea for a policy for release designation:
> > Bug-fix updates are point updates where the changing number is the third
> > section:: 3.4.0 to 3.4.1 to 3.4.2 etc.
> > Feature upgrades are minor updates and the second digit increments.
> > Wherever we are in the bugfix and security release numbering 3.4.17 would
> > next go to 3.5.0 and the next security and bugfix update would be 3.5.1.
> > Major refactorings (or perhaps the LTS release) would increment the first
> > digit. Wherever we are in the feature and bugfix updates we would jump
> > from, say, 3.5.4 to 4.0.0.
> >
> > Cheers,
> > Wolf
> >
> > --
> > This Apt Has Super Cow Powers - http://sourcefreedom.com
> > Open-Source Software in Libraries - http://FOSS4Lib.org
> > Advancing Libraries Together - http://LYRASIS.org
> > Apache Open Office Developer wolfhalton@apache.org
>
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Rob Weir <ro...@apache.org>.
On Wed, Jul 11, 2012 at 7:51 AM, Wolf Halton <wo...@gmail.com> wrote:
> On Wed, Jul 11, 2012 at 7:20 AM, Regina Henschel <rb...@t-online.de>wrote:
>
>> Hi all,
>>
>> Shenfeng Liu schrieb:
>>
>> Hi, all,
>>> Since we are stepping forward to the 3.4.1 release smoothly, I think
>>> maybe it is time for us to look ahead for our next release now.
>>>
>>> I remember we had a discussion previously on how to run AOO's future
>>> releases, time boxed vs content boxed, 3.4.1 vs 3.5 vs 4.0... I think we
>>> should resume this discussion.
>>>
>>> IMHO, timely release will give AOO a very good promotion to marketing.
>>> Certainly we can decide the size of the release. We released 3.4 at May 8,
>>> and then will release 3.4.1 after about 3 months. It looks like a very
>>> good
>>> rhythm. Maybe we can consider a 3.4.2 in 4Q, 3.5 in 1Q next year...
>>>
>>> Another way to consider is the release contents. Checking the feature
>>> requirement list and defect backlog, see what we can make after 3 months
>>> or
>>> 6 months. Or if there is any thing must be in the next release no matter
>>> how long it will take (e.g. security fix). We partially did this practice
>>> before by collecting the 4.0 requirements in wiki:
>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>> AOO+4.0+Feature+Planning<https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning>
>>> .
>>> And I remember there was a common interesting at that time that we
>>> should
>>> do an immediate release for critical defect fixes (which is 3.4.1 that we
>>> are doing now), and then a mid-term release which majorly target to
>>> fidelity improvements (3.5), and a long term release with Symphony values
>>> on UX and social integrations (4.0)...
>>>
>>> I'm not sure how to do a release proposal. Is that we should create a
>>> project wiki and discuss the release goals, contents, outlook GA date? And
>>> if we agree on this release, we move on. If we do not agree, we abandon
>>> it?
>>>
>>> I'm asking because I want to propose that:
>>>
>>> (1) We should begin to check if any critical defects in our backlog that
>>> require us for a 3.4.2.
>>>
>>> (2) We should begin to discuss a bigger release like 3.5 on the release
>>> goals, and proposed contents, and the release number...
>>>
>>> Just my 2 cents... Any suggestion/comments?
>>>
>>
>> I thought it might be useful to look in the history and have extracted
>> some dates from http://ftp-1.gwdg.de/pub/**openoffice/archive/stable/<http://ftp-1.gwdg.de/pub/openoffice/archive/stable/>
>>
>> OOo 1.0.2 2003-03-14
>> OOo 1.0.3 2003-04-18
>> OOo 1.1.0 2003-10-14
>> OOo 1.1.4secpatch 2005-04-12
>> OOo 1.1.5 2005-09-04
>> OOo 1.1.5secpatch 2006-07-04
>> OOo 1.1.5secpatch2 2006-12-22
>> OOo 2.1.0 2006-12-14
>> OOo 2.2.0 2007-03-22
>> OOo 2.2.1 2007-06-04
>> OOo 2.3.0 2007-07-14
>> OOo 2.3.1 2007-11-15
>> OOo 2.4.0 2008-03-16
>> OOo 2.4.1 2008-05-30
>> OOo 2.4.2 2008-10-27
>> OOo 2.4.3 2009-08-24
>> OOo 3.0.0 2008-10-06
>> OOo 3.0.1 2009-01-26
>> OOo 3.1.0 2009-05-04
>> OOo 3.1.1 2009-08-20
>> OOo 3.2.0 2010-02-03
>> OOo 3.2.1 2010-05-26
>> OOo 3.3.0 2011-01-18
>> OOo 3.4beta 2011-04-07
>>
>> We had the first <micro>-release after around 3 month. The next ones when
>> needed, with support of the last <minor>-release up to 1 year 3 month.
>>
>> We had <minor>-releases all 9 month (around) and <major>-release 3 years 9
>> months from OOo1 to OOo2 and 1 year 10 months form OOo2 to OOo3.
>>
>> We have to consider, that the development is no longer enterprise driven
>> and that there are less translators as before.
>>
>> Kind regards
>> Regina
>>
>
> As an enterprise-software user, I am happy not to have major releases come
> too fast. The software I mostly consume, however is operating systems and
> web apps. My opinion here may be of less value than those of people who
> support the end-users of office suites.
>
> LTS versions that are upgradeable without having to resort to installing
> the intervening versions seem valid and useful to me, and I would like the
> major versions to keep a three to five year interval. Exact interval is not
> all that important to me, I am a Debian Admin, after all. The longer the
> interval and EOL, the happier the support technicians, IMO. Microsoft
> Windows XP was production stable for 11 years and will not go out of
> support for several more years, which allowed for a very stable platform
> for development.
>
+1. This is a common enterprise requirement.
One perspective on this is here:
http://www.computerworld.com/s/article/9217896/Enterprise_IT_unhappy_with_Firefox_4_s_quick_demise
But we should go back to what is actually valuable about 'release
early, release often'. It is not about the formality of an
Apache-style release. The real importance is:
1) Developers not hoarding code until the last minute. Integrating
code earlier is better for stability
2) Allowing QA team to test earlier
3) Allow the community to see new features earlier, and offer feedback earlier
4) The increase in energy and enthusiasm that comes when we show
regular progress to ourselves and the world
If there are lightweight ways of accomplishing this, then we should
prefer those over a full Apache release. For example, dev snapshots,
perhaps more regularly build with desktop integration, would enable
all of this. Having them built directly from the Buildbot would be
idea, Then we would just need to develop a convention, like 'dev
snapshots builds will always be those made on Sunday at 1200 UTC.
Avoid risky check-ins close to that build".
As for Micro-releases, and minor releases, imagine it is a year from
now and we have made the following release:
3.4.0
3.4.1
3.4.2
3.5.0
3.5.1
3.6.0
Now a critical bug comes up, perhaps a report of a security
vulnerability. Where do we fix it?
1) If we only fix it in 3.6.1 then we will be forcing everyone to
upgrade to a new feature level, with new bugs, incompatibility,
conversion issues, etc.
2) If we fix everywhere (3.4.3, 3.5.2 and 3.6.1) then this is very
labor intensive for us. And what do we do after two years? This
quickly explodes.
3) However, if we set expectations that only certainly release are
LTS, then we only need to patch the current release and the LTS
release. For example if 3.4.0 was declared LTS, then we would release
a 3.4.3 and a 3.6.1. And even if two years had passed, and we had
3.7, 3.8, we would still only worry about the current build and the
LTS build(s).
That's why I think it is important to set expectation on this now, so
users know which track to get on, which upgrades to make, etc.
-Rob
> Individual users like features and "improvements" in UX. They are the ones
> who are upgrading whenever a point upgrade. I am one of these for my
> personal choice of office suite. I like auto-suggestions from my software
> telling me there is an update of any kind, and I usually install all
> releases if they are auto-suggested. The Firefox release schedule is only
> annoying because their plugin developers cannot keep up.
>
> As another idea for a policy for release designation:
> Bug-fix updates are point updates where the changing number is the third
> section:: 3.4.0 to 3.4.1 to 3.4.2 etc.
> Feature upgrades are minor updates and the second digit increments.
> Wherever we are in the bugfix and security release numbering 3.4.17 would
> next go to 3.5.0 and the next security and bugfix update would be 3.5.1.
> Major refactorings (or perhaps the LTS release) would increment the first
> digit. Wherever we are in the feature and bugfix updates we would jump
> from, say, 3.5.4 to 4.0.0.
>
> Cheers,
> Wolf
>
> --
> This Apt Has Super Cow Powers - http://sourcefreedom.com
> Open-Source Software in Libraries - http://FOSS4Lib.org
> Advancing Libraries Together - http://LYRASIS.org
> Apache Open Office Developer wolfhalton@apache.org
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Wolf Halton <wo...@gmail.com>.
On Wed, Jul 11, 2012 at 7:20 AM, Regina Henschel <rb...@t-online.de>wrote:
> Hi all,
>
> Shenfeng Liu schrieb:
>
> Hi, all,
>> Since we are stepping forward to the 3.4.1 release smoothly, I think
>> maybe it is time for us to look ahead for our next release now.
>>
>> I remember we had a discussion previously on how to run AOO's future
>> releases, time boxed vs content boxed, 3.4.1 vs 3.5 vs 4.0... I think we
>> should resume this discussion.
>>
>> IMHO, timely release will give AOO a very good promotion to marketing.
>> Certainly we can decide the size of the release. We released 3.4 at May 8,
>> and then will release 3.4.1 after about 3 months. It looks like a very
>> good
>> rhythm. Maybe we can consider a 3.4.2 in 4Q, 3.5 in 1Q next year...
>>
>> Another way to consider is the release contents. Checking the feature
>> requirement list and defect backlog, see what we can make after 3 months
>> or
>> 6 months. Or if there is any thing must be in the next release no matter
>> how long it will take (e.g. security fix). We partially did this practice
>> before by collecting the 4.0 requirements in wiki:
>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>> AOO+4.0+Feature+Planning<https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning>
>> .
>> And I remember there was a common interesting at that time that we
>> should
>> do an immediate release for critical defect fixes (which is 3.4.1 that we
>> are doing now), and then a mid-term release which majorly target to
>> fidelity improvements (3.5), and a long term release with Symphony values
>> on UX and social integrations (4.0)...
>>
>> I'm not sure how to do a release proposal. Is that we should create a
>> project wiki and discuss the release goals, contents, outlook GA date? And
>> if we agree on this release, we move on. If we do not agree, we abandon
>> it?
>>
>> I'm asking because I want to propose that:
>>
>> (1) We should begin to check if any critical defects in our backlog that
>> require us for a 3.4.2.
>>
>> (2) We should begin to discuss a bigger release like 3.5 on the release
>> goals, and proposed contents, and the release number...
>>
>> Just my 2 cents... Any suggestion/comments?
>>
>
> I thought it might be useful to look in the history and have extracted
> some dates from http://ftp-1.gwdg.de/pub/**openoffice/archive/stable/<http://ftp-1.gwdg.de/pub/openoffice/archive/stable/>
>
> OOo 1.0.2 2003-03-14
> OOo 1.0.3 2003-04-18
> OOo 1.1.0 2003-10-14
> OOo 1.1.4secpatch 2005-04-12
> OOo 1.1.5 2005-09-04
> OOo 1.1.5secpatch 2006-07-04
> OOo 1.1.5secpatch2 2006-12-22
> OOo 2.1.0 2006-12-14
> OOo 2.2.0 2007-03-22
> OOo 2.2.1 2007-06-04
> OOo 2.3.0 2007-07-14
> OOo 2.3.1 2007-11-15
> OOo 2.4.0 2008-03-16
> OOo 2.4.1 2008-05-30
> OOo 2.4.2 2008-10-27
> OOo 2.4.3 2009-08-24
> OOo 3.0.0 2008-10-06
> OOo 3.0.1 2009-01-26
> OOo 3.1.0 2009-05-04
> OOo 3.1.1 2009-08-20
> OOo 3.2.0 2010-02-03
> OOo 3.2.1 2010-05-26
> OOo 3.3.0 2011-01-18
> OOo 3.4beta 2011-04-07
>
> We had the first <micro>-release after around 3 month. The next ones when
> needed, with support of the last <minor>-release up to 1 year 3 month.
>
> We had <minor>-releases all 9 month (around) and <major>-release 3 years 9
> months from OOo1 to OOo2 and 1 year 10 months form OOo2 to OOo3.
>
> We have to consider, that the development is no longer enterprise driven
> and that there are less translators as before.
>
> Kind regards
> Regina
>
As an enterprise-software user, I am happy not to have major releases come
too fast. The software I mostly consume, however is operating systems and
web apps. My opinion here may be of less value than those of people who
support the end-users of office suites.
LTS versions that are upgradeable without having to resort to installing
the intervening versions seem valid and useful to me, and I would like the
major versions to keep a three to five year interval. Exact interval is not
all that important to me, I am a Debian Admin, after all. The longer the
interval and EOL, the happier the support technicians, IMO. Microsoft
Windows XP was production stable for 11 years and will not go out of
support for several more years, which allowed for a very stable platform
for development.
Individual users like features and "improvements" in UX. They are the ones
who are upgrading whenever a point upgrade. I am one of these for my
personal choice of office suite. I like auto-suggestions from my software
telling me there is an update of any kind, and I usually install all
releases if they are auto-suggested. The Firefox release schedule is only
annoying because their plugin developers cannot keep up.
As another idea for a policy for release designation:
Bug-fix updates are point updates where the changing number is the third
section:: 3.4.0 to 3.4.1 to 3.4.2 etc.
Feature upgrades are minor updates and the second digit increments.
Wherever we are in the bugfix and security release numbering 3.4.17 would
next go to 3.5.0 and the next security and bugfix update would be 3.5.1.
Major refactorings (or perhaps the LTS release) would increment the first
digit. Wherever we are in the feature and bugfix updates we would jump
from, say, 3.5.4 to 4.0.0.
Cheers,
Wolf
--
This Apt Has Super Cow Powers - http://sourcefreedom.com
Open-Source Software in Libraries - http://FOSS4Lib.org
Advancing Libraries Together - http://LYRASIS.org
Apache Open Office Developer wolfhalton@apache.org
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Regina Henschel <rb...@t-online.de>.
Hi all,
Shenfeng Liu schrieb:
> Hi, all,
> Since we are stepping forward to the 3.4.1 release smoothly, I think
> maybe it is time for us to look ahead for our next release now.
>
> I remember we had a discussion previously on how to run AOO's future
> releases, time boxed vs content boxed, 3.4.1 vs 3.5 vs 4.0... I think we
> should resume this discussion.
>
> IMHO, timely release will give AOO a very good promotion to marketing.
> Certainly we can decide the size of the release. We released 3.4 at May 8,
> and then will release 3.4.1 after about 3 months. It looks like a very good
> rhythm. Maybe we can consider a 3.4.2 in 4Q, 3.5 in 1Q next year...
>
> Another way to consider is the release contents. Checking the feature
> requirement list and defect backlog, see what we can make after 3 months or
> 6 months. Or if there is any thing must be in the next release no matter
> how long it will take (e.g. security fix). We partially did this practice
> before by collecting the 4.0 requirements in wiki:
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning.
> And I remember there was a common interesting at that time that we
> should
> do an immediate release for critical defect fixes (which is 3.4.1 that we
> are doing now), and then a mid-term release which majorly target to
> fidelity improvements (3.5), and a long term release with Symphony values
> on UX and social integrations (4.0)...
>
> I'm not sure how to do a release proposal. Is that we should create a
> project wiki and discuss the release goals, contents, outlook GA date? And
> if we agree on this release, we move on. If we do not agree, we abandon it?
>
> I'm asking because I want to propose that:
>
> (1) We should begin to check if any critical defects in our backlog that
> require us for a 3.4.2.
>
> (2) We should begin to discuss a bigger release like 3.5 on the release
> goals, and proposed contents, and the release number...
>
> Just my 2 cents... Any suggestion/comments?
I thought it might be useful to look in the history and have extracted
some dates from http://ftp-1.gwdg.de/pub/openoffice/archive/stable/
OOo 1.0.2 2003-03-14
OOo 1.0.3 2003-04-18
OOo 1.1.0 2003-10-14
OOo 1.1.4secpatch 2005-04-12
OOo 1.1.5 2005-09-04
OOo 1.1.5secpatch 2006-07-04
OOo 1.1.5secpatch2 2006-12-22
OOo 2.1.0 2006-12-14
OOo 2.2.0 2007-03-22
OOo 2.2.1 2007-06-04
OOo 2.3.0 2007-07-14
OOo 2.3.1 2007-11-15
OOo 2.4.0 2008-03-16
OOo 2.4.1 2008-05-30
OOo 2.4.2 2008-10-27
OOo 2.4.3 2009-08-24
OOo 3.0.0 2008-10-06
OOo 3.0.1 2009-01-26
OOo 3.1.0 2009-05-04
OOo 3.1.1 2009-08-20
OOo 3.2.0 2010-02-03
OOo 3.2.1 2010-05-26
OOo 3.3.0 2011-01-18
OOo 3.4beta 2011-04-07
We had the first <micro>-release after around 3 month. The next ones
when needed, with support of the last <minor>-release up to 1 year 3 month.
We had <minor>-releases all 9 month (around) and <major>-release 3 years
9 months from OOo1 to OOo2 and 1 year 10 months form OOo2 to OOo3.
We have to consider, that the development is no longer enterprise driven
and that there are less translators as before.
Kind regards
Regina
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Shenfeng Liu <li...@gmail.com>.
Pedro,
I think your comments are also very valuable to this planning thread! For
the Symphony value integration, per Symphony team's evaluation, will take 2
years or even longer for all the contents. That's why I think it is
critical to define some release in the middle to fruit. Fidelity,
performance, and other pieces like ICU & VBA that you mentioned, are some
thing important to most of our users, and relatively easy to migrate those
fixes/enhancements from Symphony. UI changes is a more complex topics, not
only from the technical perspective, but also user experience study for the
integration, which I believe will take long time for discussion. So I
suggest releases like 3.5, 3.6 to be on the way to 4.0.
- Simon
2012/7/12 Pedro Giffuni <pf...@apache.org>
> Ugh.. what I replied here was more pertinent to the
> Symphony and AOO thread, sorry.
>
> One thing that we must consider in the future for
> is being able to download incremental releases with
> binary diffs (like bsdiff). that would make it much
> easier to upgrade between micro releases.
>
> Pedro.
>
> --- Mer 11/7/12, Pedro Giffuni <pf...@apache.org> ha scritto:
> > Hi Andrea;
> >
> > --- Mer 11/7/12, Andrea Pescetti <pe...@apache.org>
> > ha scritto:
> > ...
> >
> > >
> > > Speaking with (too) little knowledge of the effort
> > involved,
> > > I would keep a 3.4.x series with periodic bugfix
> > releases,
> > > but use the trunk directly for a 4.0 release including
> > the
> > > UI changes from Symphony and the other improvements. I
> > don't
> > > see reasons for an intermediate 3.5 version unless the
> > > effort to reach 4.0 requires too long (say, one year).
> > >
> >
> > I am not an expert, but IMHO ...
> >
> > There are some lower hanging fruit: the ICU update, MSXML
> > improvements and VBA among others, that can probably be
> > easier but the nice things like the accessibility and
> > the new UI will take a lot more time.
> >
> > I can't really quantify times but adding all the Symphony
> > features into AOO would likely take more that a year and
> > can only be done properly by the IBM china guys (and we
> > are really lucky to them here).
> >
> > > Working towards version 4.0 will bring even more
> > interest
> > > towards the project and, since the changes would be
> > many and
> > > substantial, branding the release as 4.0 would be
> > totally
> > > justified.
> > >
> >
> > I certainly think we should target having the Symphony
> > UI in the future, and it does seem to fit better new
> > platforms like Windows 8, but it is really difficult
> > to know off-hand how our existing users will take it.
> >
> > At this time there is a huge inertia building around
> > Option I but I don't think we should close the doors
> > completely to option II.
> >
> > I would like to hear more from our long-time
> > developers on which approach they like best,
> > but perhaps it's not yet a good time to take
> > a decision.
> >
> > Pedro.
> >
>
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Pedro Giffuni <pf...@apache.org>.
Ugh.. what I replied here was more pertinent to the
Symphony and AOO thread, sorry.
One thing that we must consider in the future for
is being able to download incremental releases with
binary diffs (like bsdiff). that would make it much
easier to upgrade between micro releases.
Pedro.
--- Mer 11/7/12, Pedro Giffuni <pf...@apache.org> ha scritto:
> Hi Andrea;
>
> --- Mer 11/7/12, Andrea Pescetti <pe...@apache.org>
> ha scritto:
> ...
>
> >
> > Speaking with (too) little knowledge of the effort
> involved,
> > I would keep a 3.4.x series with periodic bugfix
> releases,
> > but use the trunk directly for a 4.0 release including
> the
> > UI changes from Symphony and the other improvements. I
> don't
> > see reasons for an intermediate 3.5 version unless the
> > effort to reach 4.0 requires too long (say, one year).
> >
>
> I am not an expert, but IMHO ...
>
> There are some lower hanging fruit: the ICU update, MSXML
> improvements and VBA among others, that can probably be
> easier but the nice things like the accessibility and
> the new UI will take a lot more time.
>
> I can't really quantify times but adding all the Symphony
> features into AOO would likely take more that a year and
> can only be done properly by the IBM china guys (and we
> are really lucky to them here).
>
> > Working towards version 4.0 will bring even more
> interest
> > towards the project and, since the changes would be
> many and
> > substantial, branding the release as 4.0 would be
> totally
> > justified.
> >
>
> I certainly think we should target having the Symphony
> UI in the future, and it does seem to fit better new
> platforms like Windows 8, but it is really difficult
> to know off-hand how our existing users will take it.
>
> At this time there is a huge inertia building around
> Option I but I don't think we should close the doors
> completely to option II.
>
> I would like to hear more from our long-time
> developers on which approach they like best,
> but perhaps it's not yet a good time to take
> a decision.
>
> Pedro.
>
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Pedro Giffuni <pf...@apache.org>.
Hi Andrea;
--- Mer 11/7/12, Andrea Pescetti <pe...@apache.org> ha scritto:
...
>
> Speaking with (too) little knowledge of the effort involved,
> I would keep a 3.4.x series with periodic bugfix releases,
> but use the trunk directly for a 4.0 release including the
> UI changes from Symphony and the other improvements. I don't
> see reasons for an intermediate 3.5 version unless the
> effort to reach 4.0 requires too long (say, one year).
>
I am not an expert, but IMHO ...
There are some lower hanging fruit: the ICU update, MSXML
improvements and VBA among others, that can probably be
easier but the nice things like the accessibility and
the new UI will take a lot more time.
I can't really quantify times but adding all the Symphony
features into AOO would likely take more that a year and
can only be done properly by the IBM china guys (and we
are really lucky to them here).
> Working towards version 4.0 will bring even more interest
> towards the project and, since the changes would be many and
> substantial, branding the release as 4.0 would be totally
> justified.
>
I certainly think we should target having the Symphony
UI in the future, and it does seem to fit better new
platforms like Windows 8, but it is really difficult
to know off-hand how our existing users will take it.
At this time there is a huge inertia building around
Option I but I don't think we should close the doors
completely to option II.
I would like to hear more from our long-time
developers on which approach they like best,
but perhaps it's not yet a good time to take
a decision.
Pedro.
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Andrea Pescetti <pe...@apache.org>.
Jürgen Schmidt wrote:
> 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.
Speaking with (too) little knowledge of the effort involved, I would
keep a 3.4.x series with periodic bugfix releases, but use the trunk
directly for a 4.0 release including the UI changes from Symphony and
the other improvements. I don't see reasons for an intermediate 3.5
version unless the effort to reach 4.0 requires too long (say, one year).
Working towards version 4.0 will bring even more interest towards the
project and, since the changes would be many and substantial, branding
the release as 4.0 would be totally justified.
Regards,
Andrea.
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Kay Schenk <ka...@gmail.com>.
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 <pf...@apache.org> wrote:
> >
> >> Just my $0.02
> >>
> >> --- Mar 10/7/12, Rob Weir <ro...@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
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Shenfeng Liu <li...@gmail.com>.
Juergen,
My comments below. Thanks!
- Simon
2012/7/11 Jürgen Schmidt <jo...@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
> > <jo...@googlemail.com> wrote:
> >> On 7/10/12 11:30 PM, Kay Schenk wrote:
> >>> On Tue, Jul 10, 2012 at 9:43 AM, Pedro Giffuni <pf...@apache.org> wrote:
> >>>
> >>>> Just my $0.02
> >>>>
> >>>> --- Mar 10/7/12, Rob Weir <ro...@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.
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
>
>
>
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Jürgen Schmidt <jo...@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?
>
> 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
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.
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
> <jo...@googlemail.com> wrote:
>> On 7/10/12 11:30 PM, Kay Schenk wrote:
>>> On Tue, Jul 10, 2012 at 9:43 AM, Pedro Giffuni <pf...@apache.org> wrote:
>>>
>>>> Just my $0.02
>>>>
>>>> --- Mar 10/7/12, Rob Weir <ro...@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.
>>>>
>>>
>>>
>>>
>>
>>
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Yong Lin Ma <ma...@apache.org>.
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
<jo...@googlemail.com> wrote:
> On 7/10/12 11:30 PM, Kay Schenk wrote:
>> On Tue, Jul 10, 2012 at 9:43 AM, Pedro Giffuni <pf...@apache.org> wrote:
>>
>>> Just my $0.02
>>>
>>> --- Mar 10/7/12, Rob Weir <ro...@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.
>>>
>>
>>
>>
>
>
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 7/10/12 11:30 PM, Kay Schenk wrote:
> On Tue, Jul 10, 2012 at 9:43 AM, Pedro Giffuni <pf...@apache.org> wrote:
>
>> Just my $0.02
>>
>> --- Mar 10/7/12, Rob Weir <ro...@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.
>>
>
>
>
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Jul 10, 2012 at 9:43 AM, Pedro Giffuni <pf...@apache.org> wrote:
> Just my $0.02
>
> --- Mar 10/7/12, Rob Weir <ro...@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 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.
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?
>
> 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
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Pedro Giffuni <pf...@apache.org>.
Just my $0.02
--- Mar 10/7/12, Rob Weir <ro...@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 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.
4.0 Release - Merging Symphony and perhaps adding some
new features.
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.
Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
Posted by Rob Weir <ro...@apache.org>.
On Tue, Jul 10, 2012 at 10:07 AM, Shenfeng Liu <li...@gmail.com> wrote:
> Hi, all,
> Since we are stepping forward to the 3.4.1 release smoothly, I think
> maybe it is time for us to look ahead for our next release now.
>
> I remember we had a discussion previously on how to run AOO's future
> releases, time boxed vs content boxed, 3.4.1 vs 3.5 vs 4.0... I think we
> should resume this discussion.
>
> IMHO, timely release will give AOO a very good promotion to marketing.
> Certainly we can decide the size of the release. We released 3.4 at May 8,
> and then will release 3.4.1 after about 3 months. It looks like a very good
> rhythm. Maybe we can consider a 3.4.2 in 4Q, 3.5 in 1Q next year...
>
> Another way to consider is the release contents. Checking the feature
> requirement list and defect backlog, see what we can make after 3 months or
> 6 months. Or if there is any thing must be in the next release no matter
> how long it will take (e.g. security fix). We partially did this practice
> before by collecting the 4.0 requirements in wiki:
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning.
> And I remember there was a common interesting at that time that we
> should
> do an immediate release for critical defect fixes (which is 3.4.1 that we
> are doing now), and then a mid-term release which majorly target to
> fidelity improvements (3.5), and a long term release with Symphony values
> on UX and social integrations (4.0)...
>
> I'm not sure how to do a release proposal. Is that we should create a
> project wiki and discuss the release goals, contents, outlook GA date? And
> if we agree on this release, we move on. If we do not agree, we abandon it?
>
> I'm asking because I want to propose that:
>
> (1) We should begin to check if any critical defects in our backlog that
> require us for a 3.4.2.
>
> (2) We should begin to discuss a bigger release like 3.5 on the release
> goals, and proposed contents, and the release number...
>
> Just my 2 cents... Any suggestion/comments?
>
These are good questions.
We have many kinds of users, but two big categories of users, with
different concerns, might be:
1) Individual users, who self-manage their PCs. They like getting new
features and updates. They don't want to wait a year.
2) Corporate users (but also in schools, libraries, etc.) where the
PCs are managed by an IT department. They want stable releases,
consistent quality. Frequent updates are not very welcome, especially
if they bring new bugs.
So I think this naturally leads to a two-path approach:
1) Feature work continues in the trunk, and we spin 3.x releases from
the trunk. This could be done as frequently as we want to, but each
time we do it will have overhead for us and for users. So maybe do
this only 2 or 3 times/year.
2) Declare a Long Term Support (LTS) release that we provide critical
patch support for, and commit to doing so for a longer period of time,
e.g., two years.
So users decide for themselves which track they want to be on. If
they opt for the feature track, then they will get more frequent
releases, with new features, but also new bugs. That is the trade-off
they make.
And users who opt for the LTS track will get only critical bug fixes,
but also no surprises.
Microsoft has a similar approach, of course, with a new release every
2 or 3 years, with hot fixes and service packs after each release. In
their case the patch support is long-term, 10 years even for Office
2013.
But of course the open source ethos is "release early; release often".
So we need some way to balance that as well.
One technical thing we could do to make this more manageable would be
to figure out some way to incrementally update an install without
downloading a complete package and reinstalling. This would make the
LTS versions much easier to maintain.
-Rob
> Thanks!
>
> - Simon