Etiquette: Version bump my fork of opensource project? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 7 years ago.

Improve this 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 c开发者_高级运维hanges patches?

Thanks

---

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.

---

Different pieces of software from the same code base but with different feature content should have different version numbers in some way - so you need to change something in the version number (or product name).

Do you plan to submit the first change back to the project? (You probably should.)

Is the second feature, the hack, one that you will improve over time? You might keep it on your own development branch so it is easier to maintain separately while still importing updates from the main project.

Or are you planning to stay separate from the main project in perpetuity? In that case, you should consider renaming the software as well as changing the version - or somehow making it clear that the version is yours and not theirs.

---

If you intend to fork, which is to say never merge back with upstream, then consider renaming your project.

Otherwise, it's common to use a version number that indicates the branch and changeset being ran ala -git-ross-12345