1.8.3 - May 16th, 2014

Feature

• SQL Server 2014 partial support (Details)

Fixes

• Connecting to SQL Server 2014 instances causes VS to stop responding (Details)
• CREATE TABLE AS FileTable statements cause build-time error (Details)
• Orphaned Windows Authentication (AD) logins cause Import to fail (Details)
• Unparseable scripts cause Import to fail (Details)
• Mixing OctoPack versions (v2 & v3) causes build failure (Details)
• Suppress build-time connectivity warnings (Details)
• Cancelling a deploy within MSBuild/VS does not stop SQLCMD.EXE (Details)
• Cancelling a build causes Visual Studio to stop responding (Details)

1.8.2 - March 19th, 2014

Feature

• Head-less build - You no longer need to install Visual Studio/SSDT on build agents (Details)

Fixes

• Critical issue - OctoPack error during Visual Studio 2010/2012 build; 2013 unaffected (Details)
• Failure on [__MigrationLog] deploy with SQL replication (Details)
• TargetDatabase not being retained when Default Connection String is set (Details)

1.8.1 - March 6th, 2014

Features

• 2-way sync for stored procedures, triggers, views with Deploy-Change migrations (Details)
• Integrated SQLCLR assembly development/packaging/deployment (Details)
• Provide system-defined SQLCMD variables during deployment, such as DefaultDataPath, DefaultLogPath, etc (Details)

Fixes

• Allow Deploy-Change migrations to be deployed without metadata (Details)
• Solution/Project cannot be saved when “Save new projects when created” option is unchecked (Details)
• Viewing Sync Script for programmable objects results in inadvertent object import (Details)
• Deployment preview feature for Octopus stopped working in 1.8 (Details)
• Octopus NuPkg files not working with OD’s built-in NuGet repository (Details)

1.8 - January 30th, 2014

Today’s release simplifies the way that you organise your database projects.

Over time, your database project may fill up with potentially thousands of migrations from different releases. By separating your scripts into discrete subfolders, denoted by a semantic version number, you can organize your migrations into logical groups, making your project easier to navigate and manage over time.

Project Root  
 |  
 --- 1.0.0-Baseline <-- The first folder contains the baseline scripts  
 | |
 | |-- 001_Imported-Tables.sql  
 | |-- 002_Imported-Procs.sql  
 | |-- 003_Imported-Data.sql  
 |  
 --- 1.4.0-SingleCustomerView <-- Tag your release with a descriptive label  
 | |
 | |-- 001_20130801-1210_sharrattj.sql <-- Numeric sequence restarts in each new group  
 | |-- 002_20130801-1212_sharrattj.sql  
 |  
 --- 2.0.0-Phoenix  
   |  
   |-- 01_20131123-1420_ryanp.sql <-- Vary the padding of the numeric prefix across  
   |-- 02_20131124-0930_ryanp.sql versions without affecting the order of execution

By creating a new semver folder each time you branch out a new release of your code, you can reduce the possibility of collisions occurring in your database deployments.

Read more about this feature in the documentation