Re: [Newsletter] Re: [LOG4NET] gitflow

2017-05-22 Thread Dominik Psenner 
Right now I could use the develop branch because I have made the
modifications that remove the old solution files and updates the solution
to visual studio 2015. It makes no sense to make those changes either in
the feature branch, nore the master branch but I would like to push those
changes somewhere such that anyone could merge those changes into master.
I'm starting a lazy vote now.

2017-05-22 17:59 GMT+02:00 Matt Sicker :

> The master branch holding only production tags is useful for making a
> production hotfix release. For example, this would be useful in making
> security patches. As for holding release branches, in my use of git-flow,
> I've always deleted them after merging back to develop&master, but in
> theory, it could be used for cherry-picking bug fixes and such to make
> multiple releases. Whether we'd want to support multiple version branches
> somewhat relies on how easy of a process that is for release managers to
> follow. We only use a single release train in Log4j, but that's partially
> due to the complexity in making a release.
>
> On 22 May 2017 at 08:01,  wrote:
>
> > Hi
> >
> > Gary Gregory  wrote on 19.05.2017 23:01:10:
> > > Howdy,
> > >
> > > Thank you for the link.
> > >
> > > This is fine until you want to manage more than once major version in
> > one
> > > repo, right?
> > >
> > > Over at HttpComponents, we have decided for now to keep to one repo, as
> > > opposed to one repo per major version.
> > >
> > > So ATM for example in HttpComponents' HttpCore we have a 4.4.x and
> > master
> > > branch that are BOTH going to be used for releases.
> > >
> > > How do you deal with that in Gitflow?
> >
> > As I understood gitflow, release branches are "short-living" branches,
> > only
> > used for preparation of a particular release. Once the release is shipped
> > the branch is removed.
> > If you need to support several versions of your software in the field
> > (e.g.
> > keep shipping feature updates for 2.x and 1.x; aside from hot fixes),
> > "support-brachnes" is what you're looking for. They behave like "the"
> > develop
> > branch, but for supporting older version.
> > The GitVersion Manual has some nice example images for this:
> > http://gitversion.readthedocs.io/en/latest/git-branching-
> > strategies/gitflow-examples/#support-branches
> >
> > Regards,
> > Jonas
> >
> > >
> > > Gary
> > >
> > > On Fri, May 19, 2017 at 1:10 PM, Dominik Psenner 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > would we like to use gitflow for our named branches? [1]
> > > >
> > > > [1] https://datasift.github.io/gitflow/IntroducingGitFlow.html
> > > >
> > > > Cheers
> > > > --
> > > > Dominik Psenner
> > > >
> > >
> > >
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > >  > >
> > ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> > linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8
> > > >
> > >
> > >  > > t=garygregory-20&l=am2&o=1&a=1617290459>
> > > JUnit in Action, Second Edition
> > >  > >
> > ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> > linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%
> > > 22>
> > >
> > >  > > t=garygregory-20&l=am2&o=1&a=1935182021>
> > > Spring Batch in Action
> > >  > > ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%
> > > 7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%
> > > 22%3ESpring+Batch+in+Action>
> > >  > > t=garygregory-20&l=am2&o=1&a=1935182951>
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> >
>
>
>
> --
> Matt Sicker 
>



-- 
Dominik Psenner

Re: [Newsletter] Re: [LOG4NET] gitflow

2017-05-22 Thread Matt Sicker 
The master branch holding only production tags is useful for making a
production hotfix release. For example, this would be useful in making
security patches. As for holding release branches, in my use of git-flow,
I've always deleted them after merging back to develop&master, but in
theory, it could be used for cherry-picking bug fixes and such to make
multiple releases. Whether we'd want to support multiple version branches
somewhat relies on how easy of a process that is for release managers to
follow. We only use a single release train in Log4j, but that's partially
due to the complexity in making a release.

On 22 May 2017 at 08:01,  wrote:

> Hi
>
> Gary Gregory  wrote on 19.05.2017 23:01:10:
> > Howdy,
> >
> > Thank you for the link.
> >
> > This is fine until you want to manage more than once major version in
> one
> > repo, right?
> >
> > Over at HttpComponents, we have decided for now to keep to one repo, as
> > opposed to one repo per major version.
> >
> > So ATM for example in HttpComponents' HttpCore we have a 4.4.x and
> master
> > branch that are BOTH going to be used for releases.
> >
> > How do you deal with that in Gitflow?
>
> As I understood gitflow, release branches are "short-living" branches,
> only
> used for preparation of a particular release. Once the release is shipped
> the branch is removed.
> If you need to support several versions of your software in the field
> (e.g.
> keep shipping feature updates for 2.x and 1.x; aside from hot fixes),
> "support-brachnes" is what you're looking for. They behave like "the"
> develop
> branch, but for supporting older version.
> The GitVersion Manual has some nice example images for this:
> http://gitversion.readthedocs.io/en/latest/git-branching-
> strategies/gitflow-examples/#support-branches
>
> Regards,
> Jonas
>
> >
> > Gary
> >
> > On Fri, May 19, 2017 at 1:10 PM, Dominik Psenner 
> wrote:
> >
> > > Hi,
> > >
> > > would we like to use gitflow for our named branches? [1]
> > >
> > > [1] https://datasift.github.io/gitflow/IntroducingGitFlow.html
> > >
> > > Cheers
> > > --
> > > Dominik Psenner
> > >
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> >  >
> ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8
> > >
> >
> >  > t=garygregory-20&l=am2&o=1&a=1617290459>
> > JUnit in Action, Second Edition
> >  >
> ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%
> > 22>
> >
> >  > t=garygregory-20&l=am2&o=1&a=1935182021>
> > Spring Batch in Action
> >  > ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%
> > 7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%
> > 22%3ESpring+Batch+in+Action>
> >  > t=garygregory-20&l=am2&o=1&a=1935182951>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>



-- 
Matt Sicker

Antwort: [Newsletter] Re: [LOG4NET] gitflow

2017-05-22 Thread Jonas . Baehr 
Hi

Gary Gregory  wrote on 19.05.2017 23:01:10:
> Howdy,
> 
> Thank you for the link.
> 
> This is fine until you want to manage more than once major version in 
one
> repo, right?
> 
> Over at HttpComponents, we have decided for now to keep to one repo, as
> opposed to one repo per major version.
> 
> So ATM for example in HttpComponents' HttpCore we have a 4.4.x and 
master
> branch that are BOTH going to be used for releases.
> 
> How do you deal with that in Gitflow?

As I understood gitflow, release branches are "short-living" branches, 
only
used for preparation of a particular release. Once the release is shipped
the branch is removed.
If you need to support several versions of your software in the field 
(e.g.
keep shipping feature updates for 2.x and 1.x; aside from hot fixes),
"support-brachnes" is what you're looking for. They behave like "the" 
develop
branch, but for supporting older version.
The GitVersion Manual has some nice example images for this:
http://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches

Regards,
Jonas

> 
> Gary
> 
> On Fri, May 19, 2017 at 1:10 PM, Dominik Psenner  
wrote:
> 
> > Hi,
> >
> > would we like to use gitflow for our named branches? [1]
> >
> > [1] https://datasift.github.io/gitflow/IntroducingGitFlow.html
> >
> > Cheers
> > --
> > Dominik Psenner
> >
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
>  
ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8
> >
> 
>  t=garygregory-20&l=am2&o=1&a=1617290459>
> JUnit in Action, Second Edition
>  
ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%
> 22>
> 
>  t=garygregory-20&l=am2&o=1&a=1935182021>
> Spring Batch in Action
>  ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%
> 7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%
> 22%3ESpring+Batch+in+Action>
>  t=garygregory-20&l=am2&o=1&a=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory