There are several related questions here.
What version of SqlPackage.exe to use
SqlPackage and all SSDT tools are backward compatible with SQL Server 2005. To work with any database, you must use the following version 130. It has the latest bug fixes and can focus on all publicly released versions of SQL:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\SqlPackage.exe
This will work against MSSQLLocalDB, regardless of whether it is v13.0 or v12.0.
LocalDB Instances - How They Are Created and Managed
MSSqlLocalDB is the default instance, always installed on the machine. Projects V12 and ProjectsV13 are created by SSDT using the LocalDB API . Assigning Individual Versions
- To isolate from the default instance as it is used by many other processes and project types
- To make sure we have a known version (e.g. v13) so that we can reliably publish it with the latest SQL Server features
Why do you and your colleague have different instances
Your colleague installed VS2015 Update 2 directly, without the previous version installed. This means that the old code never created an instance of ProjectV12 on its machine.
What installs MSSQLLocalDB, and what updates does it have If you previously installed LocalDB v12.0 (using SSDT as part of RTM version VS2015 or Update 1), it will connect and run MSSqlLocalDB. Consequently, he created the instance as version 12.0.
If you have never started this instance before (for example, your colleague example), then at the first start it will be launched from v13.0 LocalDB and, therefore, will receive v13.0 as the version of the instance.
As far as I know, it will not be updated from v12.0 to v13.0 at any time.
Does the version of MSSqlLocalDB matter? It depends. For most tests and special developments, this really does not matter.
If you need a version, for example, if you create mdf from .bak files for using applications, then you should use the LocalDB API to create a specific version of SQL. Just download the appropriate version of MSI, install and use the -version flag while creating the instance using the API or command line . This may be the case if you use the official SSDT publication, instead of deploying F5, although using the "Allow incompatible platform" option should work fine.