Botframework-sdk: Bot locales are not found if in a path with any upper case letter, and in linux

[greuze]

I have my locale files in path /home/ils/Projects/my-bot/locale/en-us, but before loading them, the correct full path is modified to lower case here, making the localizer to miss it, even though it exist in that path, but with an upper case letter P (in Projects).
The same code works for my team colleagues using OS X or Windows.

[Stevenic]

There's a patch coming for this...

[Stevenic]

Please install v3.4.0 which should fix the issue.

[palmerabollo]

@Stevenic 3.4.0 is not backwards compatible because, at least:

1. The class Library doesn't have a name property anymore. Correct me if I'm wrong but the new namespace property (that I don't know if correspond to the old name) is in the typings but it is NOT in the .ts code nor in the .js code. Synch between code and typings still doesn't seem to work very well.
2. ISessionOptions added a mandatory ILocalizer attribute.

At this point this is not critical for us particularly, but it should be 4.0.0 to follow semantic versioning and make npm work properly (see https://github.com/Microsoft/BotBuilder/issues/911).

[Stevenic]

So the first issue I just fixed in v3.4.2. That property name shouldn't have changed. For the second issue around changing the Session to include a mandatory property, why is that impacting you? You really shouldn't be creating a Session manually. If you are I'd like to understand what you're doing.

As for following Semver. We'd be at version 20 of the SDK if we were that rigorous. This is a pre-release SDK so there WILL be breaking changes from time to time. We try to keep them to an absolute minimum and by policy we'll only introduce a breaking change if we feel like it shouldn't impact very many (or in most cases any) bots. The Library.name change was an oversight and the required attribute change to ISessionOptions shouldn't have impacted anyone.

[Stevenic]

I should also add that we haven't really started planning the 4.0 version of the SDK yet but if I had to guess it will include a broad set of truly breaking changes. We're receiving a ton of feedback as to what's working and what isn't working with regards to the architecture of the current SDK. We're trying to add features to the SDK to better address the needs of the bot developer without breaking existing bots. This is challenging because building bots is such a bleeding edge thing. We're learning right along side you guys. I know it can seem a bit painful at times but we appreciate you guys sticking with us.

[palmerabollo]

Thanks @Stevenic. We create a Session manually in our unit tests. It's a minor issue for us, we can change it easily.

[Stevenic]

Oh I see... That's always going to be a little brittle. Currently it's assumed that the UniversalBot is always the one creating the Session so it's essentially a private interface and I'm always going to be adding & removing constructor params. You could make the argument that we shouldn't be documenting the Sessions as something you can create if that's the case but I'd hate to break your unit tests.

[Stevenic]

I'll try to minimize breaking changes to the options list in the future.