incubator-ooo-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Distinguishing Apache OpenOffice Releases
Date Sun, 11 Dec 2011 18:39:17 GMT
I don't think it is our business to replace any non-Apache install of anything, whether
or LibreOffice, Symphony, whatever.  

It might be useful to offer to import user settings from other products where those are understood
and it is benign.  I'm wary of bringing over plug-ins installed with other products.  A separate
tool for that might be worthwhile but not sure how much effort it would divert.

And there is always the question of file extension settings being associated with apps.  (There
could be multiple associations for power users if the apps didn't have identical executable
file names all stuck in soffice history.)

Finally, ignoring the technicalities of how close to 3.4-dev the first podling
release comes, that release is not an release.  Users are going to be confused
either way. I certainly don't want to get in a version-number leap-frog race with LO.  (My
calculus says LO 3.6 will be in site around that time.)

 - Dennis

-----Original Message-----
From: Rob Weir [] 
Sent: Sunday, December 11, 2011 05:25
Subject: Re: Distinguishing Apache OpenOffice Releases

On Sat, Dec 10, 2011 at 8:50 PM, Dennis E. Hamilton
<> wrote:
>  I was thinking that, to the extent that AOO is a reboot of, it would
be useful to break from the OO.o version-numbering progression in some way, especially because
the incubator releases have a special status.

Changing the naming pattern would be useful for whom?  Not the user, I
think.  Remember, the beta 3.4 was already released.  Coming out with
anything other than the final 3.4 would be confusing for users.

>  I would normally have raised this only on ooo-dev, but it is the connection with automobile
models that had me come here instead.
>  I was thinking that the incubator releases could begin their own distinct progression.
 My thought was to use identifiers like 3i4, or even A3i4 (no punctuation marks unless there
are dot releases).  There can also be A3i4-beta, a3i4-rc1, and the like.


Maybe there is a more detailed string we could put in the about box?
I have no objections to that. Ditto for encoding this in the ODF docs.
 We can use that to track dev builds, release candidates, etc.  This
is very useful for tracking defect reports, etc.

But from a branding perspective, I think we want to continue the
exiting numbering scheme.  We're trying to project continuity.

> I don't know where that goes beyond incubation.  Maybe A3x5 or whatever.  Even A4x for
starters, if it is really that dramatically different when incubation exit occurs.
> On the technical side, it should be possible to install all of these side-by-side with
each other and also with any other release built on an legacy model.  (There
should be an option to upgrade over previous A3i4, say, but it should not be forced.  That's
a matter of making it easy for someone to back out a release or beta that is a regression
for them.)

One option is to install into a separate directly, but offer to copy
settings from an exiting install of OOo or LO.  Or offer the user to
uninstall and replace an existing OOo or LO install.  Let the user


>  - Dennis

View raw message