You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An exercise is usually deprecated in prob-specs when we recommend that a different exercise is implemeted instead. Therefore an exercise that is deprecated in prob-specs should probably eventually be deprecated on the track (after implementing the replacement exercise), and configlet could advise as such.
If configlet should do it, should we do it in configlet sync, configlet info, or both?
I would say at least sync because sync is supposed to update update the "local" exercise and change based on upstream which means the maintainer would be looking for information regarding any updates to the exercise from the sync command
I don't know enough about the update process etc to give an answer but I am happy to see this question raised. My feeling was also that we currently lack some process/tooling/docs around deprecation of problem spec exercises.
Therefore an exercise that is deprecated in prob-specs should probably eventually be deprecated on the track (after implementing the replacement exercise)
Well, I've posted my thoughts on deprecating in this PR. To me, deprecation is more of a recommendation, so we'd be less
One alternative: open an issue on every track when an exercise is deprecated in prob-specs.
This is 100% something that we should be doing, as tracks could then also discuss in these issues how they'd be deprecating the exercise or possibly even why they won't.
I'm not opposed to configlet also mentioning deprecation, as long as it is a warning and does not break CI.
I would say at least sync because sync is supposed to update update the "local" exercise and change based on upstream which means the maintainer would be looking for information regarding any updates to the exercise from the sync command
This makes sense, but we'd have to carefully design how to present this information to the user.
I think it also makes sense to add the deprecation information to configlet info.
An exercise is usually deprecated in prob-specs when we recommend that a different exercise is implemeted instead. Therefore an exercise that is deprecated in prob-specs should probably eventually be deprecated on the track (after implementing the replacement exercise), and configlet could advise as such.
Prompted by exercism/problem-specifications#1921 (comment) - configlet is one way of notifying tracks that an exercise has been deprecated.
If configlet should do it, should we do it in
configlet sync
,configlet info
, or both?One alternative: open an issue on every track when an exercise is deprecated in prob-specs.
The text was updated successfully, but these errors were encountered: