Hi! > mentioned a few times now), and I think this will cause a significant > amount of pain for the people who wanna merge pull requests after the > phpng (or other similar major rewrite) is merged to the master, as they > will be required to backport the changes.
When we will have the major rewrite merged (if it will be merged into master at all and not used as separate branch), we'll deal with it, but it didn't happen yet, so I was talking about the situation now. Right now I think we should use the same model many other projects use to run development - that is, one active development branch (master) and stable branches where patches are merged into on one-by-one basis. This is also a workflow described here for features: https://wiki.php.net/vcs/gitworkflow > Ofc. when we have a diverging master we can't really save the porting, > but we could offload that work to the PR authors, and porting forward is > better documented (UPGRADING.INTERNALS) than porting backwards. Right now it is not needed since master is not that different. When it'd be needed you'd probably need separate pulls for both branches anyway, since the porting effort may be significant. If you need to test your patch on multiple branches, you also can always fork on gihtub and hook Travis CI to your private fork, and run the builds on those too. Running CI does not require a pull. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
