openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Seidel <>
Subject Re: [discussion] Release process
Date Sun, 07 Oct 2018 09:46:43 GMT
Hi Peter,

Am 07.10.2018 um 10:22 schrieb Peter Kovacs:
> Hi Jim,
> Hi Matthias,
> I had a little off list discussion with Matthias about the goal of 4.1.6.
> I would like to return this discussion to the list, and start a
> discussion on our process to do releases.
> We have said we want to make a Release once a year and try to get in
> sync with trunk quickly by making a big jump and have a beta phase.
> And then all will be easier.
> This plan is stuck, and as a reaction I have initiated a 4.1.6 in
> order to avoid security patches and updates of dependencies are
> affected by our release being stuck with this big jump.
> Matthias would really like to put also more functional code and
> feature updates in. I would like to keep the 4.1.6 release as narrow
> as it is now.

No, I want bugs to be fixed. That is what a release is for!
And I know, that many people think that optical glitches don't qualify
as a bug. But it helps to make a project look more professional... ;-)

I am OK with the current amount of code fixes, but I think we should at
least *try* to fix this bug on Linux:

AOO is incompatible with FreeType 2.8 at the moment.


> I suggest we burry the plan in making a big jump to 4.2.0 in a single
> Jump. Instead we make a create a release process that does not get
> stuck by development as long as there are code changes that can be
> released.
> In order to honor the stay independent from development in trunk, we
> create a release branch. In the release branch we test "development
> ready" patches. If they are fine, they move into the next scheduled
> release.
> A release is then tailored as we are used to do today. If they are not
> okay, we revert the patch, or fix the code. Depending on severity and
> available resources.
> Maybe it would be a good Idea to also limit the size of a release to a
> number of patches (i.e. 10. By that we limit the Release size for
> testing.)
> We could do offer an early adopter build based, in order to provide a
> simple test access.
> How about we try this? We could use a trello board to test the
> approach, and if this works out we talk how to change Bugzilla to
> follow the process.
> What do you think? Any other Ideas? I am open for all. But I would
> like to get on a base where we can move.
> Also a benefit I see from this approach I think is that we can let new
> people build on the release branch. Which should stay more stable then
> trunk. Especially with the updates we are currently doing within the
> build environment.
> All the best
> Peter
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message