On Sun, Feb 16, 2020 at 12:36 PM Dennis Luehring <dl.so...@gmx.net> wrote: > > Am 16.02.2020 um 18:27 schrieb David Edelsohn: > > On Sun, Feb 16, 2020 at 12:19 PM Dennis Luehring <dl.so...@gmx.net> wrote: > > > > > > Am 16.02.2020 um 18:03 schrieb David Edelsohn: > > > > https://gcc.gnu.org/develop.html#timeline > > > > > > > Thanks > > > > > > any idea how to reintegrate (many) changes from a release/6.3.0 branch > > > back into mainline? > > > > > > is there a tag or something where mainline was for short time in sync > > > with 6.3.0? > > > > There is no need to reintegrate changes from a release into trunk. > > The intent is that all bugs are fixed on trunk and back-ported to > > branches. The fix on a release branch may be implemented differently > > or as a work-around, but the bug is intended to be fixed in all > > release branches that still are maintained, where the bug is relevant, > > that exhibited the bug and where the benefit justifies the potential > > risk of the bug fix. > > > > Thanks David > > > i've got an older project where features where integrated based on an > 6.3.0 branch > > no bug fixes - only new features and no backporting was done :( > > > i now want to reintegrate these new features back into mainline (not > directly into head due to amount conflicts) > > but somewhere around "GCC 7 Stage 4 (starts 2017-01-20)" could work i think > > or should i try to directly merge with a 7.1 tag branch, i've no idea > how many changes where done
If you are trying to forward-port your own, proprietary features into a newer release of GCC for your own, internal use, that's your responsibility. If you wish to contribute new features to FSF GCC, they only will be accepted into trunk. You would need to integrate the feature into trunk and propose patches relative to trunk during Stage 1 development. New features are not back-ported to FSF GCC release branches. Thanks David
