Versioning of re-implementation - same idea, same name, new project and repo - 1.0.0 or 2.0.0?

Question

Assuming that we have a project called: "WizardProject".

The WizardProject, which currently stands at version 1.x.x, has a mostly Java based stack and active development has been discontinued on it.

Now, we want to bring the WizardProject back to life. Everything is new, but the same idea behind it, as well as the same name. A new repo gets created and the stack changes dramatically form Java to Python.

The new implementation of the WizardProject doesn't carry any code from the prior implementation, but obviously it is heavily inspired by version 1.x.x.

Would the implementation of the WizardProject be 2.0.0, as it is based on an existing idea? Or should it be version 1.0.0, as it is basically an all new implementation?

Answer 1

If you are asking what is the correct usage of version numbers under SemVer, then the answer is: changing from 1.0.0 to 2.0.0 would be the right thing to do, as you introduce breaking changes to the API of the app.

If you are asking about project naming and versioning practices in general, then here is the long answer.

Unless original WizardProject is so obscure, that 99 out of 100 people working in the field where WizardProject is applicable, have no clue what this software is—DO NOT NAME YOUR BRAND NEW PROJECT THE SAME NAME WITH THE SAME VERSION NUMBER.

This would be the most confusing thing ever! Imagine if linux died in the 00s and someone resurrected it 20 years later as Linux 1.0.0. This is not the movie industry—please have some standards :D

Personally, I would name it differently, even if it is a direct successor. After all, it is a completely different implementation, using a different stack, with (most likely) completely different requirements.

You could reuse the name, but never the version if two requirements are fulfilled:

• you are legally allowed to use the name;

• there is a very clear distinction in versions, so that people are sure which one they are getting.

Example 1: .NET

There were .NET Frameworks up to 4.8. During 4.6.2 the new version came out with a clearly different name .NET Core (though it was originally named .NET 5). Finally, four years later, after it was continuously pushed as a successor in promotion campaigns, the .NET Core officialy takes on the mantle and becomes .NET 5.

Example 2: Python

There is a severe distinction being made between 2.7 and 3, yet consider how long it took to actually completely switch over to the new version.

In both of these cases, the product in question is an enourmous name in the industry, with information about version difference being widely publicized (probably unlike your app). Also, in both of these cases, most of the API (at least in terms of calls) stayed the same (probably unlike your app).

TLDR: unless you are really big, or you are pretty sure that no one will confuse different versions, I'd go with a new name. Or, if you can be sure that you can clearly separate two versions in people's minds, then use the same name, but different version numbers.

Answer 2

As far as SemVer is concerned, it depends on the slightly philosophical question of whether your Python code is "a new version" or "a new project".

• If you decide that your new project should have its own brand, as PythonWizard, SemVer doesn't apply: it's a new project, and can start wherever it wants.
  • On a strict reading, it ought to start again at 1.0.
  • On the other hand, you might want to emphasise that it does everything the original did and more, so start at 2.0.
• If you keep the name WizardProject, you're branding it as a continuation, so applying SemVer and starting at 2.0 would make sense.

As an example of what not to do, I would like to point to pgAdmin, the official client tool for PostgreSQL. It has gone through four major rewrites, named "pgAdmin", "pgAdmin II", "pgAdmin III", and "pgAdmin 4". Each rewrite started again at 1.0, so at times users could choose between:

• pgAdmin II v1.6 and pgAdmin III v1.2
• pgAdmin III v1.22 and pgAdmin 4 v1.1

In my opinion, it would have been much clearer if they had stuck to either version numbers or rebranding, e.g.:

• pgAdmin v3.22 vs pgAdmin v4.1
• pgWxAdmin v1.22 vs pgJsAdmin v1.1