[discussion] Release process

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[discussion] Release process

Peter Kovacs-3
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.

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] Release process

Matthias Seidel
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:
https://bz.apache.org/ooo/show_bug.cgi?id=127805

AOO is incompatible with FreeType 2.8 at the moment.

Regards,
   Matthias

>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: [discussion] Release process

Jörg Schmidt-2
In reply to this post by Peter Kovacs-3
Hello,

> From: Peter Kovacs [mailto:[hidden email]]
> Sent: Sunday, October 07, 2018 10:22 AM
> To: dev
> Subject: [discussion] Release process

I don't want to interfere here, but I want to say the following:

> We have said we want to make a Release once a year and ...

yes, one release per year is quite optimal from the user's point of view.

(Only if necessary, security patches could be released in between, if this is concretely necessary.)



greetings
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]