I see one potential issue with using git cherry-pick in Log4j. We tend to do lots of refactorings, cleanups, etc., in between releases, so a patch may apply cleanly to 2.8.x may not apply to 2.7.x. Plus there are files with inconsistent formatting still (e.g., line endings, not following the IDE formatting files) that would need to be addressed first to help avoid these problems. Basically, there'd still need to be some manual effort to backport fixes depending on what code gets modified.
On 13 September 2016 at 01:57, Steffen Offermann < [email protected]> wrote: > The idea of release branches is to only include relevant fixes on the > branches. > > It's usually easy to "git cherry-pick" the respective commit into the > master or from master to the release branch - depending on where it got > fixed first. > > For a public project like Log4j2 there probably would be a maximum of two > actively supported release branches, so merging conflicts should not be an > issue. If master and release branch really diverge too much for "git > cherry-pick" to work, the respective change would have to be applied to > both branches manually. Since we are talking about patch-level changes, > that should not be a lot of work in 99% of all cases. > > At least that's our experience. We have been doing this for many years. > > Regards, > Steffen > > > > On 09/13/2016 08:48 AM, Ralph Goers wrote: > >> I am not concerned with running the release plugin. I am concerned when >> we have patches for the release branch that we make sure that they are also >> pushed to master. Where I work the release branch is always merged back to >> master, but that means any patches should really only be applied to the >> release branch and let master be updated when the merge is done. This can >> get quite messy. An alternative is to apply the patches to both branches >> and not merge, which runs the risk that things might be missed. To be >> honest, the reason we haven’t created release branches is because I don’t >> think any of us really want to manage that. >> >> Ralph >> >> >> On Sep 12, 2016, at 11:38 PM, Steffen Offermann < >>> [email protected]> wrote: >>> >>> >>> This is how we do it at our company: >>> >>> - start a new artifact on branch master, setting the version number in >>> pom.xml to 0.1.0-SNAPSHOT >>> - create CHANGELOG.md, add a headline "## Last Changes", and during >>> development, add an entry with a link to the respective JIRA issue for each >>> solved ticket, e.g. >>> "- [XYZ-4711](https://.../browse/XYZ-4711): Did this and that." >>> - to release v0.1.0: >>> - run "mvn release:branch -DbranchName=release-0.1.x" (using >>> 0.2.0-SNAPSHOT as the version number for the next iteration when asked) >>> - git checkout release-0.1.x >>> - edit CHANGELOG.md (i.e. replace "Last Changes" with "v0.1.0") >>> - git add CHANGELOG.md ; git commit -m"Prepared artifact for release >>> of v0.1.0" >>> - mvn release:prepare (using 0.1.0 as version number, v0.1.0 as scm >>> tag, and 0.1.1-SNAPSHOT for the next iteration's version number) >>> - mvn release:perform >>> - git push -u origin release-0.1.x ; git push -u origin v0.1.0 >>> - git checkout master >>> - edit CHANGELOG.md, adding version information "## v0.1.0" >>> - git add CHANGELOG.md ; git commit -m"Prepared artifact for >>> development of v0.2.0" ; git push -u origin master >>> - Repeat for each new release >>> >>> >>> On 09/13/2016 01:39 AM, Matt Sicker wrote: >>> >>>> It sounds like the idea is to open up a branch for each 2.x release so >>>> we can backport specific bugfixes to the previous release branch to make >>>> minor version releases. We could either fork from the >>>> last 2.6.x release to maintain a 2.6 branch, or we could start with 2.7. >>>> >>>> If there's an easy way to merge specific code changes to multiple >>>> branches, maybe we could adopt that, but I'm not exactly sure how well that >>>> would work in practice unless we fix that end of line >>>> problem that keeps popping up in certain commits (the ones that rewrite >>>> the whole file). That would cause annoying merge conflicts between major >>>> release branches. >>>> >>>> On 12 September 2016 at 17:50, Remko Popma <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> 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 < >>>> [email protected] <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Are we all caught up with the desired branches we wanted >>>> merged? >>>> >>>> On 9 September 2016 at 13:08, Remko Popma < >>>> [email protected] <mailto:[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] <mailto:[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.) >>>> >>>> -- >>>> MagineTV >>>> >>>> *Mikael Ståldal* >>>> Senior software developer >>>> >>>> *Magine TV* >>>> [email protected] <mailto: >>>> [email protected]> >>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | >>>> www.magine.com <http://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] <mailto:[email protected]>> >>>> >>>> >>>> >>>> >>>> -- >>>> E-Mail: [email protected] <mailto:[email protected]> >>>> | [email protected] <mailto:[email protected]> >>>> Java Persistence with Hibernate, Second Edition < >>>> http://www.manning.com/bauer3/> >>>> JUnit in Action, Second Edition <http://www.manning.com/tahchi >>>> ev/> >>>> Spring Batch in Action <http://www.manning.com/templier/> >>>> Blog: http://garygregory.wordpress.com < >>>> http://garygregory.wordpress.com/> >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Matt Sicker <[email protected] <mailto:[email protected]>> >>>> >>> >>> >>> -- >>> aixigo AG - financial solutions & technology >>> Karl-Friedrich-Straße 68, 52072 Aachen, Germany >>> fon: +49 (0)241 559709-65, fax: +49 (0)241 559709-99 >>> eMail: [email protected], web: http://www.aixigo.de >>> >>> Amtsgericht Aachen - HRB 8057 >>> Vorstand: Erich Borsch, Christian Friedrich, Tobias Haustein >>> Vors. des Aufsichtsrates: Prof. Dr. Rüdiger von Nitzsch >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > -- > aixigo AG - financial solutions & technology > Karl-Friedrich-Straße 68, 52072 Aachen, Germany > fon: +49 (0)241 559709-65, fax: +49 (0)241 559709-99 > eMail: [email protected], web: http://www.aixigo.de > > Amtsgericht Aachen - HRB 8057 > Vorstand: Erich Borsch, Christian Friedrich, Tobias Haustein > Vors. des Aufsichtsrates: Prof. Dr. Rüdiger von Nitzsch > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Matt Sicker <[email protected]>
