On Thu, Nov 29, 2012 at 4:48 PM, Jeff McCune <[email protected]> wrote:

> On Thu, Nov 29, 2012 at 11:56 AM, Andy Parker <[email protected]> wrote:
> > merge up through all later branches by using “--no-ff --log”
>
> With the move to semantic versioning, this recommendation has bitten
> me while maintaining stdlib.  I found that the difference between new
> functionality and bug fixes makes a big difference when merging
> something up and across major versions.  For example, consider a piece
> of new, backwards compatible functionality that we're compelled to
> merge into Puppet 3 and Puppet 4.  Assume the latest versions are
> 3.1.1 and 4.2.1 Following this guide, we would merge the change set
> into 3.x and then up through...  4.0.x => 4.1.x => 4.2.x => 4.x =>
> master.  This is where the "all" later branches gets to be tricky.
>
>
Yeah, we have that issue because of the "rift" between semver for 3 and not
for 2.7. We've probably messed it up a couple times where some new
functionality got put into 2.7 and then merged into 3.0. I think that gets
handled by trying to calm down 2.7 to just bug fixes, although that is
going to take some diligence, since it isn't what we've been doing.


> I've found for stdlib that I've needed two different merge up
> strategies depending on the type of change.  Bug fixes go into the
> oldest patch branch, let's say 3.0.x in this example, then up through
> *all* branches.  So, for example: 3.0.x => 3.1.x => 3.x ...  And
> here's where things get weird ... => 4.x => master and then again, but
> 4.0.x instead of 4.x; 3.0.x => 4.0.x => 4.1.x => 4.2.x => 4.x =>
> master.
>
> New, backwards compatible functionality is much easier:  3.x => 4.x =>
> master.  Skip all of the patch branches.
>
> Is this complexity simplified by only patching the latest minor
> release of a major release for both bugs and features?
>
>
I think that patching only the latest minor simplifies this since there
should never be a feature going onto a non-master branch, which means that
only bug fixes would ever be part of a merge-up.


> -Jeff
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to