Swift naming StorageVersionString

[ulukaya]

No description provided.

[ryanwilson]

This LGTM but since it's a breaking change, we should wait until next major version change. On that note - should we have a separate "breaking-changes" branch (Firestore has their own) to merge into. Thoughts?

[wilhuff]

If you do want a breaking-changes branch it can't be the firestore-api-changes branch since that branch will be short-lived. That branch is batching up a series of changes for the next launch vehicle available once we're ready. Firestore is still beta with a 0.x version so we can do this. The firestore-api-changes branch exists at all only because we want to minimize the number of breaking releases users might encounter.

[ryanwilson]

Right right, thanks! In that case, we should have one but not include Firestore.

[ulukaya]

@wilhuff this is FirebaseStorage, not CloudStore.
@ryanwilson yeah, branch may work, or this PR can stay till next version. Either way, don't think devs were supposed to use this variable. I may be wrong.
Only realized that our ref doc was showing this with new name (because of post processing script), vs the new ref doc generation showed still as FIR. I thought it was a mistake on the script till I saw this in repo. I'll fix the ref doc manually for now.

[wilhuff]

@ulukaya Agreed that this is about storage. I was merely pointing out that it should stay separate from Firestore -- that you shouldn't appropriate firestore-api-changes as a staging ground for your own breaking changes.

[paulb777]

We need to make a coherent version naming strategy for all components. CocoaPods automatically generates version variables like this when it creates (dynamic) frameworks.

[paulb777]

I was thinking about working on a consistent global Firebase versioning scheme for M25, but that's not going to happen.

With approval from @schmidt-sebastian, we should go ahead and merge this for M25