Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
3  
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
    
Out of curiosity, what did you fork? –  compman Dec 29 '10 at 14:48

5 Answers 5

up vote 10 down vote accepted

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

share|improve this answer

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.

share|improve this answer
1  
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
1  
@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 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

share|improve this answer

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.

share|improve this answer
1  
Moving from "Python 1.1" to "Userthon 1.1.{DATE}" breaks the expected format of verison numbers. –  DougM Feb 24 at 0:17

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)
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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