Conversation
timrogers
left a comment
timrogers
left a comment
There was a problem hiding this comment.
There definitely are breaking change concerns with this update, but I still think we should make the jump and fix this behaviour - especially before GA.
At worst, it'll be a minor annoyance if your script which used to run now waits, and you can change it!
What do you think of adding a temporary warning for a version or two to give users a heads-up about the change in behaviour?
Just to make sure I understand your suggestion, you are suggesting we first roll out a change that adds the Because I considered doing it that way, but the fact that we are not actually breaking anybodies scripts, we're just making them run slower made me lean towards just pulling the bandaid off all at once. But I'll defer to your opinion on this one. |
|
I was thinking that we change the default immediately, but add a temporary log line as a heads up about the change. |
Oh I see, so maybe a warning is somebody runs it without either |
|
Exactly. That's what I was thinking. |
| Output = new FileInfo(OUTPUT), | ||
| Verbose = true, | ||
| NoSslVerify = true | ||
| NoSslVerify = true, |
There was a problem hiding this comment.
that's on purpose, and generally considered a good practice. Makes it easier to add new lines/properties after it, and the subsequent diff will be cleaner.
|
…ate-repo` and `migrate-org` Up until April, the default behavior of `migrate-repo` and `migrate-org` was to exit immediately after queueing the migration, and not to wait for it to complete. Users could opt in to the "wait" behaviour using the `--wait` option. In April, we [flipped][1] these defaults around, making waiting the default and adding the `--queue-only` option for the old behavior. This meant that the `--wait` option could go away - but we wanted to do this in a user-friendly, backwards-compatible way. At that time, we deprecated the `--wait` option, hiding it from the in-CLI documentation and printing warning when it's used. These warnings have been in place for 3 months, so now is a reasonable time to rip off the band aid and remove the argument. After this change is released, specifying the old `--wait` option will cause the CLI to error. Fixes #1082 and #1059. [1]: #929
3 participants
--waitflag #946ThirdPartyNotices.txt(if applicable)Implements #705
Changing the default behavior of
migrate-repoandmigrate-orgto be the same as the--waitflag.The
--waitflag is now unnecessary, but for compat reasons I'm leaving it in. I made it a hidden option, and if you pass it you'll get this warning:--wait flag is obsolete and will be removed in a future version. The default behavior is now to wait.Added a new option
--queue-onlywhich will result in the same behavior as the previous default behavior.Also updating
generate-scriptcommands to include the--queue-onlyflag for parallel scripts (and remove--waitfrom the sequential scripts).For customers that have pre-existing parallel scripts (without the
--waitflag) this will result in a change in behavior (scripts that used to be parallel will now run sequentially), but it shouldn't break their scripts (the integration tests confirm this). Anybody that relies on the default behavior will start getting a warning that says:[WARNING] The default behavior has changed from only queueing the migration, to waiting for the migration to finish. If you ran this as part of a script to run multiple migrations in parallel, consider using the new --queue-only option to preserve the previous default behavior.. In a future release we'll remove this warning.Any existing sequential scripts will continue to work just fine, they will just see warnings about using an unnecessary
--waitflag now.Added validation that both
--waitand--queue-onlycan't be passed in together.