Are we all caught up with the desired branches we wanted merged?

On 9 September 2016 at 13:08, Remko Popma <[email protected]> wrote:

> What is our thinking on this for the upcoming release?
>
> On Fri, Sep 2, 2016 at 8:22 PM, Mikael Ståldal <[email protected]>
> wrote:
>
>> On LOG4J2-1548, Remko Popma
>> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=remkop%40yahoo.com>
>>  wrote:
>>
>> I'm okay with changing the process but we need to think through the
>>> implications of maintaining multiple branches. I don't mind fixing a bug
>>> in, say, the 2.7.x maintenance branch and merging that fix also into the
>>> 2.8 new features branch, but what do we do with subsequent releases?
>>> Once we are on version 2.10, and we receive a bug report against version
>>> 2.7, do we add a fix to the maintenance branches 2.7.x, 2.8.x and 2.9.x in
>>> addition to the 2.10 new feature branch? When do we stop supporting old
>>> maintenance branches?
>>>
>>
>> I think we should make sure that we can always easily make patch releases
>> on the latest minor release (like 2.6.3 now), and do so whenever a serious
>> bug is discovered and fixed (like LOG4J-1548).
>>
>> I don't think that we should normally make patch releases on older minor
>> releases (like 2.5.1 now) though. That should only be done in exceptional
>> cases, and we should not prepare for it any more than keeping a tag for
>> each release in Git.
>>
>> I also think that we should consider ways of reducing the number of
>> serious issues introduced in minor releases, such as making a public beta
>> release before a minor release. (I was not really satisfied with the
>> quality of the 2.6 release, and I think we should try to do better in the
>> future.)
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> [email protected]
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>
>


-- 
Matt Sicker <[email protected]>

Reply via email to