Define the steps to safely rename an exercise

[kytrinyx]

This problem has come up a couple of times, and there are currently ongoing discussions regarding whether or not to rename exercises.

In the past it has been done, but it is not trivial, and the process was not well defined. It resulted in a significant amount of pain and confusion.

There are a few things that we should account for when deciding on a series of steps.

Someone who has already completed the exercise under the old name:

• should still be able to see their own solution to the exercise
• should still be able to see other people's solution to the exercise
• should be able to see (and provide feedback on) solutions to both the old and new exercise
• should not receive the new exercise to solve by default, as they've already solved it

Someone who has not completed it under the old name:

• should receive only the new exercise, not both

Someone who has completed the exercise under the new name:

• should be able to see (and provide feedback on) solutions to both the old and new exercise
• should not receive the old exercise

We need to decide what should happen if you try to explicitly fetch the old exercise (currently you are allowed to fetch deprecated exercises).

We have previously updated old records in the database to reflect the new exercise slug, but because many things rely on this bit of data, there were unexpected consequences.

We must also take into account that the some tracks might perform the rename whereas others might not, or might do so on a different schedule.

[kytrinyx]

@jtigger commented in a thread about deprecation: #120 (comment)

do we every truly want to allow an exercise's identity to be mutable? This comes-up prominently in the "Change Name" scenario. What would happen if we consider an exercise, despite its near identical content to another exercise merely as a new one? Old submissions stay with the old exercise; new stay with the new.

Per this, an option is to create the new exercise, deprecate the old one, and let people get the nearly identical exercise again and either submit it or skip it.

Or, treat them as separate exercises, but create a script that "skips" all the new exercises for everyone who has already solved the old version of it. Or a script that creates a notification to everyone who has solved it that there is a new one that is almost identical, and they can skip it if they like.

[iHiD]

Is there any reason that the top level specifications couldn't have a slug as an uuid, and then the individual tracks can name them as they see fit? The uuid is the identifier used everywhere internally and the name is just a piece of metadata that's shown to users etc. That name can be inherited from the specification on creation, but then changed manually if required by different tracks.

In terms of nextercism, I don't see any of your bullet points as a problem on the website side if the name is decoupled/unimportant from the specification, and if the github code used uuids instead of meaningful names, then I think the problem wouldn't exist there either. But I don't know that side of the codebase really at all so might be missing something.

Thoughts?

[kytrinyx]

@iHiD I think I need a specific example / case study to understand what you mean.

[kytrinyx]

Now that exercises have a UUID, we no longer need to worry about exercise renames.

See exercism/meta#16