Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sync/info: mention exercises that are deprecated in prob-specs, but not track #498

Open
ee7 opened this issue Jan 18, 2022 · 3 comments
Open
Labels
cmd: sync kind: feature User-facing enhancement

Comments

@ee7
Copy link
Member

ee7 commented Jan 18, 2022

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.

@ynfle
Copy link

ynfle commented Jan 18, 2022

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

@junedev
Copy link
Member

junedev commented Jan 18, 2022

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.

@ErikSchierboom
Copy link
Member

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.

@ee7 ee7 added cmd: sync kind: feature User-facing enhancement labels Jan 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cmd: sync kind: feature User-facing enhancement
Projects
None yet
Development

No branches or pull requests

4 participants