-1

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?

1
  • 1
    Are you absolutely sure that a new name is not appropriate for this project? Dec 14, 2020 at 19:37

2 Answers 2

3

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.

5
  • I'm not sure the .NET Framework / .NET Core case is the best example: in practice, nobody used the term ".NET Framework" before .NET Core came along, and plenty of people were confused for a good few years when .NET Core did come along. Dec 14, 2020 at 12:50
  • Well, thanks first of all for this detailed answer @Heagon! Yeah, I'm kind of tied to the name "WizardProject" and can't choose a different name. So I guess, I've to stick to the version. Dec 14, 2020 at 12:58
  • @Heagon: So a new repository would also use internally 2.0.0, even though it doesn't contain the 1.0.0 tag? Dec 14, 2020 at 13:12
  • Awesome! Just incase you would know, are there any supporting docs you would know of to back the fact that SemVer would suggest using 2.0.0? Apparently versioning can be very opinionated subject. :D Dec 14, 2020 at 13:27
  • @tschaka1904: "are there any supporting docs you would know of to back the fact that SemVer would suggest using 2.0.0? Apparently versioning can be very opinionated subject" – The whole point of SemVer is that there is a clearly defined set of semantics for version numbers and a clearly defined set of criteria for when to change what part of the version number and how to change it. However, this only makes sense if you have a clearly specified public interface. Otherwise, the terms "backwards-compatible" or "backwards-incompatible" do not make sense. Dec 14, 2020 at 16:30
1

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
3
  • Philosophical... that hits the nail on the head😅 The python code is somewhat a new project, but at the same time a replacement for something already existing. Another issue for me as well is, when keeping the same name as well, you’ll end up with 2-n WizardProject on some point. “Are we talking about the “old”, “old old” or the “new” WizardProject?” Dec 14, 2020 at 17:28
  • @tschaka1904 Indeed, which is exactly what happened with pgAdmin. I think if you want to "brand" the project as a new 1.0, you need to make the name as different as possible while still making people think of the original, e.g. WizardProject -> WitchProject, not WizardProject -> WizardProjectNG.
    – IMSoP
    Dec 14, 2020 at 18:03
  • How would you version this case: a giant monolith v2.x.x , which gets torn into many smaller modules preserving same functionality and extending it? Dec 14, 2020 at 20:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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