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 <wolf.hal...@gmail.com> a
écrit :
On Wed, Jul 11, 2012 at 7:20 AM, Regina Henschel <rb.hensc...@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
