Question

This question is about etiquette and open source projects.

I have forked an application from github and added two new features.

1. The first feature has been request frequently elsewhere. I have added it. Code & implementation are clean (I think).

2. The second feature is more of a hack. It will be of use to others, but the implementation is a little dirty in useage and more so in code. I need the feature but I don’t have the skills to fully implement it properly or to a level that could be considered a worth while contrabution to the main project.

How should the versioning work? Do I just bump up my version numbers care-free and push to my master branch?

It is annoying to know which version is running, modifed or original, as both have the same version number. But will it be confusing when, months later, my github page has a version number the same as the original but both are actually completely different. (I have made pull requests etc. but that is not the context of my question.)

The project I have forked uses ruby jeweler so has a versioning format of:

Jeweler tracks the version of your project. It assumes you will be using a version in the format x.y.z.

x is the ‘major’ version, y is the ‘minor’ version, and z is the patch version.

Is this standard for other projects/langauges too? Are my changes patches?

Thanks

Answer 1

This can’t be answered easily. Version number handling varies between projects and your goals. Do you see your fork as a temporary issue? – Then, in many cases (might be different with larger rewrites for example), I won’t increase the version number as it is up to the project leader to do.

Many versioning schemes allow to extend the version number to something like 1.2.3-ross, which helps users filing proper bug reports.

If you plan a longer running fork you should find a versioning scheme which works for you.