redhat-developer
Experimental mode
/kind user-story
User Story
As a user I want to define ODO_EXPERIMENTAL So that I can use experimental commands and flags
Acceptance Criteria
When ODO_EXPERIMENTAL=true
- [ ] It should display in the header the command is running in Experimental mode
- [ ] It should enable experimental commands, which are not visible otherwise
- [ ] It should enable experimental flags, which are not visible otherwise
Links
- Related Epic (mandatory): #5865
/kind user-story
I'm speaking from an unpleasant experience in the past.
Having gone through one instance of moving things from experimental mode to normal mode, I humbly request not to go down this route again and find a different way of pushing new features. The myriad of if..else conditions it leads to and then removing those conditions when we want to take the feature(s) out of the experimental mode is not worth it, IMHO.
A few ideas that come to my mind:
- Don't cut a release till we are sure that something is baked well.
- Have a separate v3 branch, like we have the v2 branch. But v2 was slated for deprecation, v3 isn't/won't.
- Keep doing releases every sprint like we do now, but have a warning on the website and repo that informs the users about the WIP nature of things and the unreliability that it entails.
I'm speaking from an unpleasant experience in the past.
Having gone through one instance of moving things from experimental mode to normal mode, I humbly request not to go down this route again and find a different way of pushing new features. The myriad of
if..elseconditions it leads to and then removing those conditions when we want to take the feature(s) out of the experimental mode is not worth it, IMHO.
I can imagine some solutions to limit the problems for code maintenance.
For example, by defining Features, which are themselves defined as Experimental or not, and use conditions on these Features
For example, by defining Features, which are themselves defined as Experimental or not, and use conditions on these Features
I don't understand. :(
I'm speaking from an unpleasant experience in the past.
Having gone through one instance of moving things from experimental mode to normal mode, I humbly request not to go down this route again and find a different way of pushing new features. The myriad of
if..elseconditions it leads to and then removing those conditions when we want to take the feature(s) out of the experimental mode is not worth it, IMHO.
I know that last time the situation with the experimental flag was not ideal.
We have things to learn from past mistakes. Not by not doing it. But trying to do it better.
If we want to work on bigger features, we need a mechanism like this
A few ideas that come to my mind:
- Don't cut a release till we are sure that something is baked well.
We want to keep doing time-based released, it works pretty well for us.
- Have a separate v3 branch, like we have the v2 branch. But v2 was slated for deprecation, v3 isn't/won't.
Adding new features into a separate branch can create a lot of problems when you need to merge them into the main branch. The whole release process is more complex, and it can create a lot of uncertainties.
- Keep doing releases every sprint like we do now, but have a warning on the website and repo that informs the users about the WIP nature of things and the unreliability that it entails.
Repo and website won't be enough, we would have to add it to the CLI (command description) as well.
@feloy added one more acceptance criterion. Experimental flags/commands should not be hidden (not showing up in help, but otherwise working), but completely disabled (they should not exist in "normal" mode and error out if user tries to use them)