I have forked a project and have changed lots of it. This fork isn't just a small feature change here and a buried bug fix there, its a pretty substantial change. Only most of the core code is shared.

I forked this project at v2.5.0. For a while I've started versioning my fork at v3.0 . However I'm not sure if this is the right way, mainly because when that project hits v3.0, things get confusing. But I don't want to start over at v1.0 or v0.1 because that implies infancy, instability, and non-refindness of a project. This isn't true, as most of the core code is very refined and stable.

I'm really lost on what to do, so I ask here: Whats the standard way to deal with this kind of situation? Do most forks start over again, bump up version numbers, or do something else that I'm not aware of.

  • 5
    I don't see how 1.0 imlies infancy or instability. Anything below 1.0 yes, but 1.0 implies it's out of 'infancy' period and ready to rock. If it makes you more comfortable, go with 1.1 (10% extra maturity!!!) ;)
    – Mchl
    Dec 29, 2010 at 10:53
  • 1
    Out of curiosity, what did you fork?
    – compman
    Dec 29, 2010 at 14:48

5 Answers 5


Most forks that I've seen start again from version 1.0. But I assume you've also changed the name of your fork, so I'm not sure why there would be confusion if you simply started from v3.0.

What I would do is change the name of the project, release version 1.0 and make it clear that the project is a fork of another project. I don't think there will be any confusion with that approach.

If you're really worried about the "1.0" label, simply release version 2.0 a short time after 1.0...

  • ...or release v2.0 directly, skipping v1.0 altogether. It wouldn't be the first time that this is done.
    – Konamiman
    Jul 17, 2015 at 11:00
  • At my company one project started at v2.4 even.
    – user253751
    Sep 27, 2017 at 0:02

Have your own roadmap and stick to it, starting with the original version's number but don't try to race with the current version of the original product.

  • 2
    If you're not trying to parallel the original project in some way, then there will be no meaningful correlation between version numbers going forward. That means there's no point trying to establish such a correlation now - by starting at 3.0 - because it will only establish an unfulfillable expectation. Dec 29, 2010 at 16:05
  • I stand corrected. You should start your very own v1.0, that will help you differentiate. Versions should mean something, not just some marketing stunt (v.gr. "v5.4" just not to look new). Dec 29, 2010 at 21:27
  • 2
    @TomAnderson: If he forks at, say, version 2.5, and makes the first version of his fork either 2.6 or 3.0, he can point to the other app as the complete history of his project. Which is a modestly meaningful correlation.
    – DougM
    Feb 24, 2014 at 0:19

You might want to consider if (and how much) your project is going to be related with the original one. If you plan on porting new features from the original project into your, you might consider keeping your version numbers matching versions of the original.

As an example check out MariaDB, which is a fork of MySQL. They want to keep it a 'drop-in' replacement for MySQL, so for example MariaDB 5.2 has all the features of MySQL 5.2.

See: http://kb.askmonty.org/v/mariadb-versus-mysql

Note: Since this answer been posted, MariaDB has diverged substantially from MySQL and is now following its own versioning scheme.


0.1 may indicate infancy, but verion 1.0+ means stable. A increase in major version numbers eg 2.0, 3.0, generally indicated a large feature change.


  • Version 1.0 of my application was a tool for running test scripts with setup,
  • Version 2.0 removed the differentiation between test scripts and environment setup scripts,
  • Version 3.0 added a GUI for writing scripts as flow charts. They are recognisably different products, but even Version 1 was a working product, completely stable etc. Versions 2 and 3 came about because it was decided these big changes would be good. If we hadn't have wanted these big changes, and had have just continued doing bug fixes etc. Minor version numbers would have just increased, 1.10,1.20 etc, and that would have been fine.

What I am saying is major version numbers don't indicated maturity, they indicate major feature sets. Now that was a bit of a tangent from how to version number your product.

What I've seen before, which I quiet liked was start versioning again from 1.0 (or from 3.0 if you really prefer) and then in brackets saying which version of the original it last had features pulled from.

  • Initially:" MyFork v1.1 (based on OrigProg v3.0)
  • Some improvenets made to MyFork: MyFork v1.3 (based on OrigProg v3.0)
  • OrigProg released a major version and MyFork pulled and merged: MyFork v2.1 (based on OrigProg v4.0)
  • Made some major changes to MyFork (probably won't be be able to easily merge with OrigProg ever again): MyFork v3.0 (based on OrigProg v4.0)

If at all possible, merge your fork back to the original project. I cannot emphasize this enough.

Regaeding your version numbers, then use the one you forked from plus a date suffix.

  • 2
    Moving from "Python 1.1" to "Userthon 1.1.{DATE}" breaks the expected format of verison numbers.
    – DougM
    Feb 24, 2014 at 0:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.