Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of liushenf@gmail.com designates
 209.85.212.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAP-ksoh_Ct5hSZveydEtBEExdnMFdT_pHC85foHHqc8rWsbesw@mail.gmail.com>
References: 
 <CANQgRaZb903fAAJHHQNhkt9NxMsXFykiVRT5_1YhNKrO4fOygg@mail.gmail.com>
	<4FFD6184.5010902@t-online.de>
	<CALRLYEn70JUwzV6=pdpSZrmw9PL_uAtKU6udwsFpOp1zWQ9-PQ@mail.gmail.com>
	<CAP-ksoh_Ct5hSZveydEtBEExdnMFdT_pHC85foHHqc8rWsbesw@mail.gmail.com>
Date: Wed, 11 Jul 2012 22:29:29 +0800
Message-ID: 
 <CANQgRab9iLEag_ue4sB4UgPt6jfDgHqNOknwppfJE8xhv6xFvQ@mail.gmail.com>
Subject: Re: [RELEASE] Next Release - 3.4.2? 3.5? 4.0?
From: Shenfeng Liu <liushenf@gmail.com>
To: ooo-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d043c06e6bc601604c48eac61

--f46d043c06e6bc601604c48eac61
Content-Type: text/plain; charset=ISO-8859-1

Hi, Rob,
  My comments below.

- Simon

2012/7/11 Rob Weir <robweir@apache.org>

> On Wed, Jul 11, 2012 at 7:51 AM, Wolf Halton <wolf.halton@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
>

--f46d043c06e6bc601604c48eac61--