Tell me more ×
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.
up vote 6 down vote favorite
2

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

4 Answers

up vote 9 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
up vote 2 down vote

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
up vote 2 down vote

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
up vote 0 down vote

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

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.