Back to the discussion about the release process, concretely what are we going to do differently from what we do now?
On Sat, Sep 10, 2016 at 3:26 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > Remko has a branch to merge. > > I'd like to hear from Steffen Offermann > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=SteffenO> who > has been testing master... > > Gary > > On Fri, Sep 9, 2016 at 11:13 AM, Matt Sicker <boa...@gmail.com> wrote: > >> Are we all caught up with the desired branches we wanted merged? >> >> On 9 September 2016 at 13:08, Remko Popma <remko.po...@gmail.com> wrote: >> >>> What is our thinking on this for the upcoming release? >>> >>> On Fri, Sep 2, 2016 at 8:22 PM, Mikael Ståldal < >>> mikael.stal...@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.stal...@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. >>>> >>> >>> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >> > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory >
