How to handle pull requests to original repo with changes dependent on a newer version of the compiler

Question

I have a github project that I've forked. The original repo was written for a version of OCaml before version 4.02.1. The 4.02.1 compiler gives me various deprecation warnings which I plan on fixing and committing to my repo. I'm not sure if I should push my changes back to the original project.

My question is: in a situation where code from a third-party (me) requires a newer version of a library or compiler than the original author/project is using, how should I handle sharing my code with the original repo? It seems inconsiderate to just offer the new code without some kind of explanation and I certainly don't want to break the build on the original repo.

How is this kind of situation handled?

Answer 1

I'll describe how this is typically handled in github. However all of that is just code, so it is relevant elsewhere.

Really spiffy projects like the ones I run, have tests to make sure everything is working okay.

Furthermore, the way cool projects like the ones I work with have some sort of continuous integration. That just means there is a way for some external independent system to run the tests on its own. github arranges a project to used a canned set of git commit hooks which will tell the independent system that a change has been commited.

Usually there are instructions that you can provide to the continuous integration system that help it build the system. Specifically these instructions or configuration might specify what version(s) of OCaml to test with.

With all of this in place, when you submit a "pull request", github runs the git hook which kicks off the continous integration system which then makes available the status of the check. Github will then notice it (because the hook was canned and custom for a ci so it knows where to look). And then it will alert the potential owner whether it is safe to merge the code or not. Even without continuous integration github will do a merge off to the side just to make sure there are no merge conflicts.

Ok. But let's suppose you are working with less sophisticated projects. Since this is git, that's cool too, it can help you on its own.

Here what you could do then is make a branch and restrict your changes to that branch. Then request a pull from that branch. The owner will probably merge your changes into a similarly-named branch and then try it out. If things work okay, then that person will merge the branch into the "main" branch.

And in fact whether you are using github and the fancy stuff or not, it is always good to work in a branch for your changes off of another project. See also git flow

Answer 2

It's really no different than any other change. If it's a significant amount of work, run it by the mailing list first. Someone may already be working on it. If it's a trivial amount of work, just do it and submit a pull request with a clear explanation. The worst that will happen is it will get rejected.

Deprecation is done for different reasons, and often your changes can be made backward-compatible to older language versions. Try to do so if you can. For example, ISO-latin1 characters in identifiers were added to deprecation warnings in 4.02. You can certainly compile identifiers without ISO-latin1 characters in older versions.