On Thu, Nov 22, 2012 at 5:24 PM, Dave Fisher <dave2w...@comcast.net> wrote: > > On Nov 22, 2012, at 9:21 AM, Rob Weir wrote: > >> On Thu, Nov 22, 2012 at 11:36 AM, Dave Fisher <dave2w...@comcast.net> wrote: >>> >>> On Nov 22, 2012, at 3:50 AM, Jürgen Schmidt wrote: > > <snip> > >>>> Exactly, we would release the new languages only on base of 3.4.1 and a >>>> new src release. When we do a further 3.4.2 release we can build the new >>>> languages in the same way as the others. >>> >>> I think that we will need a new source release - we could call the source >>> release "3.4.1b". >>> >> >> It depends on what is in the source release. If the tarball contains >> only the newly added PO translation files, then it could be called >> 3.4.1 without any confusion. Let's avoid any code changes, since >> that merely complicates future upgrades. > > It would need to be called 3.4.1 supplemental language lack or something like > that. > >>> It would give us good practice at voting on a release based on simple IP >>> scans with RAT and svn diff to prove that the only changes are language >>> files. We trust, but we must verify. >>> >> >> If the only thing included in the source tarball are PO files then the >> proof is rather simple, yes? Just include the PO files, the LICENSE >> and NOTICE and a README that says to unzip these files over the >> already released full 3.4.1 source tarball. RAT scan of the PO files >> should be easy enough (assuming it understands PO files). Otherwise >> we can manually inspect the files for license headers. > > Sure - either way it would be a 3.4.1 source artifact. > > The README would describe how to put the language pack over the 3.4.1 source > release. > > I'll leave it up to Jürgen to choose a 3.4.1 source language supplement, a > fuil 3.4.1b source release, or a 3.4.2 source release w/ all that implies. > > But in general the supplement w/convenience binaries does make the most > sense. What I don't want is to see another 3.4.1 source release with the same > name, that would be wrong. >
+1 We certainly need some unique name to call it. But if we're not updating the source code (the C++ code) then we're probably not updating the version number in the Help/About box and in other runtime metadata. This is not a revision of OpenOffice. I really want to avoid needing to introduce new version fields in Bugzilla, new update service URL's, new upgrade test paths, new download paths, etc. So when we talk about calling this "3.4.1b", we need to be clear in what systems this new name would exist. We usually rev them all when we have a functionally new release. Revising none of them, except the source tarball, would work as well. Of course, we can always tell that this is "Apache OpenOffice 3.4.1b (or whatever we call it) based on the language. If it is in Danish, Polish, etc., then we know it is this 2nd release. (I assuming this 2nd edition includes only the new languages, not a re-release of the pre-existing ones). > I suspect that this issue with new Languages coming in after a release will > continue until we have covered the whole world. > > Perhaps we should have a naming convention for source releases that includes > the date or revision number. Then each can continue to be simple to use > source releases that are contained and need no supplements. > > Choice 1 - new source language packs are supplements to a version. 3.4.1b > type naming. > > Choice 2 - new source language packs are re-releases of source packages for a > version. 3.4.1-20130101 (or svn rev) > > Another reason to have supplements or re-releases would be for build fixes or > new platform builds. > > Regards, > Dave > >> >>> I don't have any strong opinions regarding whether we hurry for a 3.5 or >>> develop a feature rich and well tested 4.0. Once we reach consensus on this >>> issue we should have Marketing publish the plan so the user base will know >>> what to expect with an estimated timeline - emphasis on estimated. >>> >>> Regards, >>> Dave >>> >>> >>>> >>>> Juergen >>> >
