Closed davidsteinsland closed 6 years ago
Maybe deprecate. Ie support bother fasit and nais prefix, and print a warning.
Then give a deadline for when it will change
The default environment is a bit risky. Have you considered no default value here
Make people think about environment. That might make then consider having fewer
I'm not quite sure about the deprecation warning. If people update the nais
cli, they should (in my mind) also check for any breaking changes. If they update, but don't check for changes, how can we be sure that they check the output of nais
(for example if the nais deploy
is part of a jenkins pipeline) and catch the warning?
Failing hard is sometimes necessary in order to force a change.
The environment change is simply because I think that the q
env class is better suited for the preprod cluster than the t
env class.
I just think it's nais to be nice about breaking backwards compatibility. This might be helpful for some users, but will not help all.
Regarding env classes. I want it to be painful to use environments.
And it might be confusing for users when a tool changes behaviour, in a sort of invisible way.
I agree with David, adding backwards compatibility doesn't really make sense when its a minor change in pipelines
I don't think changing t0
to q0
makes it easier for people to have their app deployed multiple times in different namespaces. And vice versa, it doesn't make it harder for people if we remove the default value.
i'm merging the changes, but I agree that some form of changelog would be nice to have. if not for users but for ourselves, so we know which version introduced what BC break/promise..
USER
if username is emptyNAIS_
toFASIT_
to avoid confusion (breaks BC)t0
toq0
(breaks BC)