Hi, How would we get patches from open-edx or latest releases from open-edx if we fork the current version and make customizations on top of it. We are new to open-edx and we are looking to make customizations on top of it. What would be the best way to customize without hampering the ability to pull latest changes or releases from openedx? Any guidance or help is appreciated, Thanks.
That’s a good question. My company (OpenCraft) has dealt with this a lot and we recommend that you avoid forking the Open edX platform if at all possible, for exactly that reason - the more you customize your fork, the harder it is to maintain, and the more work is required for applying security patches or upgrading to the new release.
Instead, try to build your customizations using the platform’s many extension points. If you read through that document carefully, you’ll see that a huge range of customizations is possible without actually forking the platform. And if you want to do something that’s not currently possible with the existing extension points, I encourage you to create a new extension point to make it possible, and then contribute that extension point to the platform so that everyone can benefit and you can avoid having to maintain a fork.
If you want more specific guidance, please give us an idea of what sort of customizations you have in mind.
We wanted to add some additional questions types and evaluation methods in the LMS. As you suggested there were extension points that we could use to implement this. So well be focusing our efforts in using this extension points instead of customizing the open edx codebase unnecessarily. Thank you.
If you’re asking about the mechanics of maintaining a fork, here’s what it would look like:
- Fork the repository
- Create a branch that will be your main branch (let’s call it
- Deploy off of
sam-main, branch from it, and merge into it as needed – but keep this to an absolute minimum, as Braden recommends
- As often as possible, fetch latest
masterfrom the origin repository and merge it into
sam-main. Maybe do this on a weekly cadence.
The requirements files might need special handling, you’d have to be prepared to handle a lot of merge conflicts, and this would need to be done for every IDA that you want to fork… but technically, it should work. : )
You might find that you need to do this just temporarily in order to apply a security patch, or to add an extension point before you can contribute it back upstream (or find an alternative), so this also doesn’t have to be a process you use forever.
Thanks @Tim_McCormack for mentioning the specifics.