logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Release process
Date Fri, 09 Sep 2016 18:08:20 GMT
What is our thinking on this for the upcoming release?

On Fri, Sep 2, 2016 at 8:22 PM, Mikael Ståldal <mikael.staldal@magine.com>
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*
> mikael.staldal@magine.com
> 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.
>

Mime
View raw message