18

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,478
  • 7
  • 55
  • 87
  • 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 '10 at 10:53
  • 1
    Out of curiosity, what did you fork? – compman Dec 29 '10 at 14:48

5 Answers5

14

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,871
  • 3
  • 51
  • 70
7

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
  • 13,943
  • 6
  • 50
  • 77
  • 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. – Tom Anderson Dec 29 '10 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). – dukeofgaming Dec 29 '10 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 '14 at 00:19
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,103
  • 1
  • 22
  • 23
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
  • 894
  • 6
  • 18
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 '14 at 00:17