20

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.

TheLQ
  • 13,650
  • 7
  • 56
  • 88

5 Answers5

15

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...

Dean Harding
  • 19,911
8

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.

dukeofgaming
  • 14,023
  • 6
  • 52
  • 77
4

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.

Mchl
  • 4,113
1

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.

Eg

  • 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)
Frames Catherine White
  • 932
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.