Contribute to cphalcon project

Hi there,

Can anyone provide step by step contribution procedure (gitflow) of cphalcon github project? in:

  • pull request flow and rules
  • new fetures
  • bug fixes
  • etc

I want to contribute but I dont know how and where to start corrctly!

P.S: I know how to use git.

Thanks in advance.

edited Jun '16

There is phalcon repository:

https://github.com/phalcon/cphalcon

Master repo is LAST released version and any pull requests are not accepted here.

2.0.x is finished and we no longer accept pull requests here. We focus on 2.1.x now, on finish up 2.1.0 version and releste it, it will be LTS version. I hope that we will finally use semantic versioning(i created issue on github), so 2.1.1 and next versions will be only bug fixes and small changes, like adding some new method for returning already done in existing code.

I guess when 2.1.0 will be released then there will be 2.2.x as well for new futures - some of them are already waiting currently but i guess that dev team decided to postpone them to 2.2.x.

If you want to implement some new feature then you need to learn zephir lang - https://zephir-lang.com, there is zephir forum - https://forum.zephir-lang.com. Each PR must contain tests(if it's something new), updated changelog and docs if needed(documentation is generated from them). If you know PHP well and other languages then it shouldn't be a problem, keep in mind that everything from php doesn't work yet in zephir. It's not 1:1, few things are missed.

Also there are two directories for tests, use this one - https://github.com/phalcon/cphalcon/tree/2.1.x/tests, this is old tests https://github.com/phalcon/cphalcon/tree/2.1.x/unit-tests and in future it will be removed after all tests will be rewritten/redone.

Also when you are doing additional commits to your fork remember about squashing all commits into one at end, just to keep history clean.

Also if you are implemnting new future you should write about it in documentation too - https://github.com/phalcon/docs, i mean only somelanguage/ref, api is generated from zephir classes - that's why you need to add docs to them for some simple code examples.

edited Jun '16

@Jurigag, Thank you for your helpfull info.

Actually I mean the complete process of forking in github, coding, remoting, pull requests ... I'm new in github and I want to combine and refine my knowledges in my private git development process (in my current local projects) with cphalcon's github process flow!

  • should I fork the repo first then use it/checkout
  • what about remoting/tracking master repo
  • should I create new branch for each changes and commit to it then create new pull request on top of it?
  • what is the step by step procees you guys do in daily commits in cphalon

P.S: I know how to program with zephir

Thanks

Just fork repo first and use it. I am for each new feature pushing to new branches so my 2.1.x, etc branches(phalcon branches) keep clean and i just do pull from usptream on them to keep them up-to-date with phalcon repo, then im doing pull request with this my new branch and phalcon 2.1.x repository.

If there are any new commit in phalcon, im just doing rebase and resolving conflicts and squashing my commits.



44.8k

Phalcon is sort of Semanticly Versioned as long as you understand that it isn't exactly. 2.1 will live for three years and will be completely compatible with itself. The next version if its called 2.2 or 3.0 will likely break stuff and so you might as well just assume it is the next major version and currently I personally don't recommend putting a strong Phalcon dependeny in a project's composer file because it will break and the 2.1 release candidate uses its own wonky non-semver name so that will also break it. Its not a big deal since Phalcon has very few point releases and just assume that there will be breakage until the next version. I suppose that used to be a bit of an issue but with the 2.1 LTS for 3 years after release it hardly matters.