Release Engineering

assigned_to: cloph@openoffice.org

-------- Weitergeleitete Nachricht --------
Betreff: [Bug 108709] cli_ assemblies are not correctly versioned
Datum: Wed, 16 Aug 2017 12:06:07 +0000
Von: bugzilla-daemon@bugs.documentfoundation.org
An: cloph@documentfoundation.org

Michael Stahl <mailto:mstahl@redhat.com> changed bug 108709
<https://bugs.documentfoundation.org/show_bug.cgi?id=108709>
What Removed Added
Status UNCONFIRMED NEW
CC   cloph@documentfoundation.org, mstahl@redhat.com, sbergman@redhat.com
See Also   https://bz.apache.org/ooo/show_bug.cgi?id=117009,
https://bz.apache.org/ooo/show_bug.cgi?id=111878,
https://bz.apache.org/ooo/show_bug.cgi?id=104650,
https://bz.apache.org/ooo/show_bug.cgi?id=102355,
https://bz.apache.org/ooo/show_bug.cgi?id=98038
Ever confirmed   1

*Comment # 1
<https://bugs.documentfoundation.org/show_bug.cgi?id=108709#c1> on bug
108709 <https://bugs.documentfoundation.org/show_bug.cgi?id=108709> from
Michael Stahl <mailto:mstahl@redhat.com> *

afaik there is nobody in the project who actually knows anything
about CLI; all that's been done there in LO is that some guy
migrated the code from a deprecated C++ on CLI dialect
to a not deprecated C++ on CLI dialect, and the 64 bit port.

so it looks like these versions are stored in:
cli_ure/version/version.txt

git log of that file indicates all the *_NEW_VERSION were
incremented in their 3rd digit, while the *_OLD_VERSION
were incremented to cover the previous value of *_NEW_VERSION,
and the *_POLICY_VERSION incremented so its 1st digit
matches the 3rd digit of *_NEW_VERSION.

this happened once for every OOo release, 3.4, 3.3, 3.2, 3.1.1, 3.1...

so i suppose we should adapt a similar approach?

bumping it once per x.y branch should be enough?

i predict this is not going to happen reliably unless Cloph
adds it to some release-engineering checklist.

------------------------------------------------------------------------
You are receiving this mail because:

• You are on the CC list for the bug.