+1  A: 

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.

Jonathan Leffler
Ross
+2  A: 

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.

johannes
+1  A: 

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

Scott Robinson