[hmate9]

Some people are used it, prefer it and probably it would break some automated tests people have too.

[thombat]

Workflow: https://xkcd.com/1172/

[tester756]

who cares?

I hate this approach because this is very lazy (you avoid thinking about hard stuff and pick easy solution) and is very short term

sure you can introduce 150 configuration modes

but it makes your thing messy, confusing for new people, confusing for inexperienced and requires more maintenance

it's like taking tech debt

[junon]

> who cares?

Loads of people who have to maintain things.

[Minor49er]

This is a standard approach to software development: you introduce a new alternative for something that exists, then mark the existing inferior option as "deprecated". This gives developers a chance to learn about the new feature and move over to it by the time it actually gets removed in a future version. Cutting it immediately would cause a huge amount of frustration since the users of the feature would demand to know where it went or why it suddenly no longer works while the maintainers would have to scramble to find a solution. It would turn people off from using that software in the future.

[tester756]

The thing is that

>by the time it actually gets removed in a future version.

doesn't always happen, so we're left with new, new v2, new v3 options and old one still exists "because it may break somebody's workflow"

[Minor49er]

I would argue that for most cases, that's preferable to simply cutting old functionality. The only exception would be in environments where the upgrade process is more rigid where users/admins know what's changing with an upgrade and have a safe and easy way to roll back in case of any issues.