diff --git a/Gemfile b/Gemfile
deleted file mode 100644
index 16b448279..000000000
--- a/Gemfile
+++ /dev/null
@@ -1,32 +0,0 @@
-# frozen_string_literal: true
-source "https://rubygems.org"
-
-# Hello! This is where you manage which Jekyll version is used to run.
-# When you want to use a different version, change it below, save the
-# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
-#
-# bundle exec jekyll serve
-#
-# This will help ensure the proper Jekyll version is running.
-# Happy Jekylling!
-gem "jekyll", "~> 3.8.5"
-
-# # This is the default theme for new Jekyll sites. You may change this to anything you like.
-# gem "minima", "~> 2.0"
-
-# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
-# uncomment the line below. To upgrade, run `bundle update github-pages`.
-# gem "github-pages", group: :jekyll_plugins
-
-# If you have any plugins, put them here!
-group :jekyll_plugins do
- gem "jekyll-feed", "~> 0.6"
- gem "jekyll-redirect-from"
- gem "jekyll-paginate"
-end
-
-# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
-gem "tzinfo-data", platforms: [:mingw, :mswin, :x64_mingw, :jruby]
-
-# Performance-booster for watching directories on Windows
-gem "wdm", "~> 0.1.0" if Gem.win_platform?
diff --git a/Gemfile.lock b/Gemfile.lock
deleted file mode 100644
index 43b54c6e3..000000000
--- a/Gemfile.lock
+++ /dev/null
@@ -1,81 +0,0 @@
-GEM
- remote: https://rubygems.org/
- specs:
- addressable (2.6.0)
- public_suffix (>= 2.0.2, < 4.0)
- colorator (1.1.0)
- concurrent-ruby (1.1.5)
- em-websocket (0.5.1)
- eventmachine (>= 0.12.9)
- http_parser.rb (~> 0.6.0)
- eventmachine (1.2.7)
- eventmachine (1.2.7-x64-mingw32)
- ffi (1.11.1)
- ffi (1.11.1-x64-mingw32)
- forwardable-extended (2.6.0)
- http_parser.rb (0.6.0)
- i18n (0.9.5)
- concurrent-ruby (~> 1.0)
- jekyll (3.8.5)
- addressable (~> 2.4)
- colorator (~> 1.0)
- em-websocket (~> 0.5)
- i18n (~> 0.7)
- jekyll-sass-converter (~> 1.0)
- jekyll-watch (~> 2.0)
- kramdown (~> 1.14)
- liquid (~> 4.0)
- mercenary (~> 0.3.3)
- pathutil (~> 0.9)
- rouge (>= 1.7, < 4)
- safe_yaml (~> 1.0)
- jekyll-feed (0.12.1)
- jekyll (>= 3.7, < 5.0)
- jekyll-paginate (1.1.0)
- jekyll-redirect-from (0.15.0)
- jekyll (>= 3.3, < 5.0)
- jekyll-sass-converter (1.5.2)
- sass (~> 3.4)
- jekyll-watch (2.2.1)
- listen (~> 3.0)
- kramdown (1.17.0)
- liquid (4.0.3)
- listen (3.1.5)
- rb-fsevent (~> 0.9, >= 0.9.4)
- rb-inotify (~> 0.9, >= 0.9.7)
- ruby_dep (~> 1.2)
- mercenary (0.3.6)
- pathutil (0.16.2)
- forwardable-extended (~> 2.6)
- public_suffix (3.1.1)
- rb-fsevent (0.10.3)
- rb-inotify (0.10.0)
- ffi (~> 1.0)
- rouge (3.5.1)
- ruby_dep (1.5.0)
- safe_yaml (1.0.5)
- sass (3.7.4)
- sass-listen (~> 4.0.0)
- sass-listen (4.0.0)
- rb-fsevent (~> 0.9, >= 0.9.4)
- rb-inotify (~> 0.9, >= 0.9.7)
- tzinfo (2.0.1)
- concurrent-ruby (~> 1.0)
- tzinfo-data (1.2019.3)
- tzinfo (>= 1.0.0)
- wdm (0.1.1)
-
-PLATFORMS
- ruby
- x64-mingw32
-
-DEPENDENCIES
- jekyll (~> 3.8.5)
- jekyll-feed (~> 0.6)
- jekyll-paginate
- jekyll-redirect-from
- tzinfo-data
- wdm (~> 0.1.0)
-
-BUNDLED WITH
- 2.1.4
diff --git a/Jenkinsfile b/Jenkinsfile
deleted file mode 100644
index a00299fcf..000000000
--- a/Jenkinsfile
+++ /dev/null
@@ -1,51 +0,0 @@
-pipeline {
- options {
- timestamps()
- buildDiscarder(logRotator(numToKeepStr: '10', artifactNumToKeepStr: '5', artifactDaysToKeepStr: '45'))
- withAWS(credentials: 'JenkinsUserAtAWS')
- }
-
- agent {
- node {
- label 'dockerBuilder'
- }
- }
-
- environment {
- GITHUB_AUTH = credentials('github-auth')
- ART_AUTH = credentials('artifactory-auth')
- }
- stages {
- stage('staging-cd') {
- when {
- branch 'staging'
- }
- steps {
- echo 'Building and Deploying Jekyll `_site/` to Staging.'
- script {
- sh 'export JEKYLL_VERSION=3.8 && \
- docker run \
- --volume="$PWD:/srv/jekyll" \
- jekyll/jekyll:$JEKYLL_VERSION \
- jekyll build'
- s3Upload(file:'_site', bucket:'staging.liquibase.org', path:'')
- }
- slackSend channel: '#liquibase_pro_website',
- color: 'good',
- message: "Liquibase Staging Site Updated: http://staging.liquibase.org"
- }
- }
- }
- post {
- success {
- slackSend channel: '#jenkinsbuilds',
- color: 'good',
- message: "SUCCESSFUL: Job '${JOB_NAME} [${BUILD_NUMBER}]' (${env.BUILD_URL})"
- }
- unsuccessful {
- slackSend channel: '#jenkinsbuilds',
- color: 'bad',
- message: "FAILED: Job '${JOB_NAME} [${BUILD_NUMBER}]' (${env.BUILD_URL})"
- }
- }
-}
diff --git a/README.md b/README.md
index f72162ed3..5524c3ac6 100644
--- a/README.md
+++ b/README.md
@@ -1,80 +1,16 @@
-# liquibase.github.io
+# doc generator
-Documentation for the liquibase.org site.
+This directory contains source code for java program that will generate all the documentation for the
+various change types that liquibase supports. These are found in this github project at
+`liquibase.github.com/documentation/changes/`
-***Please send pull requests!***
+To re-build the doc generator and run it, just run `mvn clean package` in this directory. You may want
+to update the POM so that it uses the version of liquibase you want to document.
-## Project Overview
-
-The Liquibase site is hosted using GitHub Pages, and generated using [Jekyll](http://jekyllrb.com/). Pages are written in MarkDown documents, making use of [Liquid template tags](http://jekyllrb.com/docs/templates/).
-
-To build the site for local testing, install Jekyll and its dependencies, including Ruby, the kramdown gem, Python 2.7, and the Pygments package. If you're developing on Windows, there is a handy [Portable package of Jekyll](https://github.com/madhur/PortableJekyll) you can use. You may still need to fiddle around a bit to get it working, such as installing the kramdown gem ("gem install kramdown") and editing "setpath.cmd".
-
-Once Jekyll is installed, just navigate to this repo's directory, and run `jekyll serve`. You can then access the site from `http://localhost:4000`.
-
-If you're using a MarkDown editor with a "live preview" feature, be aware that it's unlikely to support Liquid's syntax highlighting tags, such as "{% highlight xml %}".
-
-## Project Setup
-### Requirements (Bundler)
-* [Ruby](https://ruby-doc.org/)
- * _OR_ [RVM](https://rvm.io/rvm/install)
-* [Bundler](https://bundler.io/)
-
-### Steps
-#### Bundler
-##### Install
-Once all requirements are met, you can install everything with:
-```bash
-bundle install
-```
-
-##### Local Dev Server
-```bash
-bundle exec jekyll serve
-```
-_Or_
-```bash
-bundle exec jekyll serve -l
-```
-The -l option specifies "live reload" to automatically refresh your browser when a content change is complete.
-
-#### Local Server
-To access the local development server navigate to: `127.0.0.1:4000` (the default Jekyll port).
-
-### Requirements (Docker)
-Or if you'd prefer to run everything through a docker container:
-* [Docker](https://www.docker.com/)
-
-#### Docker
-```bash
-./scripts/docker-dev.sh
-```
-
-### CI/CD Overview
-#### Staging (staging.liquibase.org)
-To see your changes in a `staging` environment, base your PRs on the `staging` branch. When the PR is merged to staging, a build server will
-generate the site and publish it to [http://staging.liquibase.org/](http://staging.liquibase.org/) within about 10 minutes. After review by the team,
-staging will be merged to master (typically within 1 business day).
-
-#### Production (liquibase.org)
-To see the changes in `production` a merge must be made into `master`. GitHub Pages will handle the deployment.
-
-
-## Sub-sections that are generated
-There are several sub-sections of the site that are generated. Two are listed below.
-
-### Changes docs
-The first generated section is all the documentation for the built-in Liquibase
-change types (both Core and Pro). The process for generating these is not currently automated by CI/CD, and is documented
-in the [README.md file in the _doc_generators directory](_doc_generators/README.md)
-
-### Maven Plugin Docs
-The second generated section is the documentation for the Liquibase Maven Plugin. The process for generating these docs
-and incorporating them into this site:
-* clone the [liquibase core source code](https://github.com/liquibase/liquibase)
-* run `mvn -DskipTests package site` to compile and package the code, and then generate maven-style site documentation. Most of that documentation will not get used.
-* copy files from `liquibase/liquibase-maven-plugin/target/site` to `liquibase.github.com/documentation/maven/generated`
- * There is a shell script in the root of this project `copyMavenDocs.sh` that will copy the correct files for you.
-* double check the diffs and then commit the changes.
+It will create `liquibase-docgenerator-1.0.0.local-SNAPSHOT.jar` in the root of the project. Switch to
+that directory and then run `java -jar liquibase-docgenerator-1.0.0.local-SNAPSHOT.jar` to execute.
+Running the `generateChangeDocs.sh` in the root of the project accomplishes both of the steps above in
+one swell foop.
+Check the diffs before comitting the changes.
diff --git a/_config.yml b/_config.yml
deleted file mode 100644
index 078ba22e5..000000000
--- a/_config.yml
+++ /dev/null
@@ -1,77 +0,0 @@
-safe: true
-lsi: false
-# # Welcome to Jekyll!
-# #
-# # This config file is meant for settings that affect your whole blog, values
-# # which you are expected to set up once and rarely edit after that. If you find
-# # yourself editing this file very often, consider using Jekyll's data files
-# # feature for the data you need to update frequently.
-# #
-# # For technical reasons, this file is *NOT* reloaded automatically when you use
-# # 'bundle exec jekyll serve'. If you change this file, please restart the server process.
-
-# # Site settings
-# # These are used to personalize your new site. If you look in the HTML files,
-# # you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
-# # You can create any custom variable you would like, and they will be accessible
-# # in the templates via {{ site.myvariable }}.
-# title: Your awesome title
-# email: your-email@example.com
-# description: >- # this means to ignore newlines until "baseurl:"
-# Write an awesome description for your new site here. You can edit this
-# line in _config.yml. It will appear in your document head meta (for
-# Google search results) and in your feed.xml site description.
-# baseurl: "" # the subpath of your site, e.g. /blog
-# url: "" # the base hostname & protocol for your site, e.g. http://example.com
-# twitter_username: jekyllrb
-# github_username: jekyll
-
-# Build settings
-markdown: kramdown
-permalink: /:year/:month/:title.html
-# theme: minima
-# plugins:
-# - jekyll-feed
-
-paginate: 10
-paginate_path: "/blog/page_:num/"
-
-plugins:
-- jekyll-redirect-from
-- jekyll-paginate
-
-sass:
- sass_dir: _scss
-
- # Exclude from processing.
-# The following items will not be processed, by default. Create a custom list
-# to override the default setting.
-exclude:
-# - Gemfile
-# - Gemfile.lock
-# - node_modules
-# - vendor/bundle/
-# - vendor/cache/
-# - vendor/gems/
-# - vendor/ruby/
- - scripts/
- - gradle/
- - gradlew
- - converters/
- - '*.bat'
- - '*.sh'
- - '*.gradle'
- - '*.groovy'
- - '*.jar'
- - '*.log'
- - Jenkinsfile
- - .idea
-# For own gh-pages
- - javadoc/
- - docs/
- - blog/
-
-# For gh-pages
-baseurl: /liquibase-doc
-# for jekyll 4 replace {{site.baseurl}}{% link to {% link
-
diff --git a/_doc_generators/.gitignore b/_doc_generators/.gitignore
deleted file mode 100644
index eb5a316cb..000000000
--- a/_doc_generators/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-target
diff --git a/_doc_generators/README.md b/_doc_generators/README.md
deleted file mode 100644
index 5524c3ac6..000000000
--- a/_doc_generators/README.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# doc generator
-
-This directory contains source code for java program that will generate all the documentation for the
-various change types that liquibase supports. These are found in this github project at
-`liquibase.github.com/documentation/changes/`
-
-To re-build the doc generator and run it, just run `mvn clean package` in this directory. You may want
-to update the POM so that it uses the version of liquibase you want to document.
-
-It will create `liquibase-docgenerator-1.0.0.local-SNAPSHOT.jar` in the root of the project. Switch to
-that directory and then run `java -jar liquibase-docgenerator-1.0.0.local-SNAPSHOT.jar` to execute.
-
-Running the `generateChangeDocs.sh` in the root of the project accomplishes both of the steps above in
-one swell foop.
-
-Check the diffs before comitting the changes.
diff --git a/_doc_generators/src/main/java/org/liquibase/doc/check/DocChecker.java b/_doc_generators/src/main/java/org/liquibase/doc/check/DocChecker.java
deleted file mode 100644
index 47a13ee00..000000000
--- a/_doc_generators/src/main/java/org/liquibase/doc/check/DocChecker.java
+++ /dev/null
@@ -1,111 +0,0 @@
-package org.liquibase.doc.check;
-
-import liquibase.util.file.FilenameUtils;
-
-import java.io.*;
-import java.util.Arrays;
-import java.util.HashSet;
-import java.util.Set;
-import java.util.regex.Matcher;
-import java.util.regex.Pattern;
-
-public class DocChecker {
- public static void main(String[] args) throws Exception {
- Set files = new HashSet();
- findFiles(new File("_site"), files);
-
- Set seenFiles = new HashSet();
- for (File file : files) {
- checkLinks(file, seenFiles);
- checkContent(file);
- }
- for (File file : files) {
- if (!file.getAbsolutePath().contains("javadoc") && !seenFiles.contains(file.getCanonicalPath())) {
- System.out.println("Found no references to "+file.getAbsolutePath());
- }
- }
- }
-
- private static void checkContent(File file) throws IOException {
- BufferedReader reader = new BufferedReader(new FileReader(file));
- String line;
- String contents = "";
- while ((line = reader.readLine()) != null) {
- contents += line;
- }
-
- if (contents.contains("Unknown Nav")) {
- System.out.println("Problem with navigation in "+file.getAbsolutePath());
- }
-
-
- }
-
- private static void checkLinks(File file, Set seenFiles) throws Exception {
- BufferedReader reader = new BufferedReader(new FileReader(file));
- String line;
- String contents = "";
- while ((line = reader.readLine()) != null) {
- contents += line;
- }
- for (String url : findUrls(contents)) {
- File dir = file.getParentFile();
- if (url.startsWith("http")) {
- continue;
- }
- if (url.startsWith("mailto")) {
- continue;
- }
- if (url.endsWith(".md")) {
- System.out.println("Reference to markdown "+url+" in "+file.getAbsolutePath());
- }
- File referencedFile = new File(dir, url);
- try {
- seenFiles.add(referencedFile.getCanonicalPath());
- } catch (IOException e) {
- System.out.println("Bad file "+referencedFile);
- e.printStackTrace();
- continue;
- }
- if (referencedFile.isDirectory()) {
- System.out.println("Reference to directory "+url+" in "+file.getAbsolutePath());
- }
- if (!referencedFile.exists()) {
- System.out.println("Reference to missing "+url+" in "+file.getAbsolutePath());
- }
- }
- }
-
- private static Set findUrls(String contents) {
- Set returnSet = new HashSet();
- Matcher matcher = Pattern.compile("href=[\"']?([\\w:/\\.\\-]+)[\"']?").matcher(contents);
- while (matcher.find()) {
- returnSet.add(matcher.group(1));
- }
-
- matcher = Pattern.compile("src=[\"']?([\\w:/\\.\\-]+)[\"']?").matcher(contents);
- while (matcher.find()) {
- returnSet.add(matcher.group(1));
- }
-
- return returnSet;
- }
-
- private static void findFiles(File dir, Set files) {
- files.addAll(Arrays.asList(dir.listFiles(new FilenameFilter() {
- @Override
- public boolean accept(File dir, String name) {
- return name.endsWith(".html");
- }
- })));
-
- for (File subdir : dir.listFiles(new FileFilter() {
- @Override
- public boolean accept(File pathname) {
- return pathname.isDirectory();
- }
- })) {
- findFiles(subdir, files);
- }
- }
-}
diff --git a/_doc_generators/src/main/java/org/liquibase/doc/generator/ChangeDocGenerator.java b/_doc_generators/src/main/java/org/liquibase/doc/generator/ChangeDocGenerator.java
deleted file mode 100644
index 826a1b3f2..000000000
--- a/_doc_generators/src/main/java/org/liquibase/doc/generator/ChangeDocGenerator.java
+++ /dev/null
@@ -1,646 +0,0 @@
-package org.liquibase.doc.generator;
-
-import j2html.tags.ContainerTag;
-import j2html.tags.Tag;
-import liquibase.change.*;
-import liquibase.change.core.*;
-import liquibase.change.custom.CustomChangeWrapper;
-import liquibase.changelog.ChangeSet;
-import liquibase.database.Database;
-import liquibase.database.DatabaseFactory;
-import liquibase.database.core.HsqlDatabase;
-import liquibase.database.core.MSSQLDatabase;
-import liquibase.database.core.MySQLDatabase;
-import liquibase.database.core.OracleDatabase;
-import liquibase.resource.AbstractResourceAccessor;
-import liquibase.resource.ClassLoaderResourceAccessor;
-import liquibase.resource.CompositeResourceAccessor;
-import liquibase.serializer.LiquibaseSerializable;
-import liquibase.serializer.LiquibaseSerializable.SerializationType;
-import liquibase.serializer.core.json.JsonChangeLogSerializer;
-import liquibase.serializer.core.xml.XMLChangeLogSerializer;
-import liquibase.serializer.core.yaml.YamlChangeLogSerializer;
-import liquibase.sql.Sql;
-import liquibase.sqlgenerator.SqlGeneratorFactory;
-import liquibase.statement.SqlStatement;
-import liquibase.util.StringUtils;
-import org.slf4j.Logger;
-import org.slf4j.LoggerFactory;
-import org.slf4j.Marker;
-import org.slf4j.MarkerFactory;
-
-import java.io.*;
-import java.util.*;
-import java.util.stream.Stream;
-
-import static j2html.TagCreator.*;
-
-public class ChangeDocGenerator {
-
- private static final Logger logger = LoggerFactory.getLogger(ChangeDocGenerator.class);
- private static final Marker statsMarker = MarkerFactory.getMarker("STATS:");
-
- public static void main(String[] args) throws Exception {
- logger.info("Generating documentation for all changes in included jar");
- Map>> definedChanges = ChangeFactory.getInstance().getRegistry();
- TreeMap>> sortedChanges = new TreeMap<>(definedChanges);
-
- List databases = DatabaseFactory.getInstance().getImplementedDatabases();
- Collections.sort(databases, new Comparator() {
- @Override
- public int compare(Database o1, Database o2) {
- return o1.getDatabaseProductName().compareTo(o2.getDatabaseProductName());
- }
- });
- writeChangeNav(sortedChanges);
- writeChangePages(sortedChanges, databases);
- }
-
- private static void writeChangeNav(Map>> definedChanges) throws Exception {
- // Ensure the directory exists so we know we are running in the right place.
- File includesDir = new File("_includes");
- if (!includesDir.exists() || !includesDir.isDirectory()) {
- logger.error("The directory '" + includesDir.getAbsolutePath() + "' was not found. Copy the jar file to the root directory of the project and re-run.");
- System.exit(1);
- }
-
- String content = "";
- content = addGeneratedHeader(content);
- content += "
Note: If not set, then the first valueXXX defined is used in the order
- they appear.
-
-
-
-
valueNumeric
-
integer value of the parameter.
-
-
-
valueBoolean
-
boolean value of the parameter.
-
-
-
valueDate
-
Date and/or Time value to set the parameter to. The value shall be specified in one of the
- following forms: "YYYY-MM-DD", "hh:mm:ss" or "YYYY-MM-DDThh:mm:ss".
-
-
-
valueComputed
-
A value that is returned from a function or procedure call. This attribute shall contain the function name to call.
-
-
-
valueSequenceNext
-
Name of the sequence which next value is used
-
-
-
valueSequenceCurrent
-
Name of the sequence which current value is used
-
\ No newline at end of file
diff --git a/_includes/components/announcement.html b/_includes/components/announcement.html
deleted file mode 100644
index 17f882d6c..000000000
--- a/_includes/components/announcement.html
+++ /dev/null
@@ -1,4 +0,0 @@
-
Note: If not set the first valueXXX defined is used in the order they
- appear.
-
-
-
valueNumeric
-
integer value of the column.
-
-
-
valueBoolean
-
boolean value of the column.
-
-
-
valueDate
-
Date and/or Time value to set the column to. The value is specified in one of the following forms: "YYYY-MM-DD", "hh:mm:ss" or "YYYY-MM-DDThh:mm:ss".
-
-
-
valueComputed
-
A value that is returned from a function or procedure call. This attribute shall contain the function name to call.
-
-
-
valueBlobFile
-
Path to a file, whose contents will be written as a BLOB (i.e. chunk of binary data).
- Must be either absolute or relative to the Change Log file location (absolute paths are, e.g.:
- /usr/local/somefile.dat on Unix or c:\Directory\somefile.dat on Windows. Please refer to
- java.io.File javadoc
- for the details of what to consider relative/absolute path).
-
-
-
valueClobFile
-
Path to a file, whose contents will be written as a CLOB (i.e. chunk of character data).
- Must be either absolute or relative to the Change Log file location (absolute paths are, e.g.:
- /usr/local/somefile.daton Unix or c:\Directory\somefile.dat on Windows.
- Please refer to java.io.File javadoc
- for the details of what to consider relative/absolute path).
-
-
-
encoding
-
Name of the encoding (as specified
- in java.nio.Charset javadoc)
- of the CLOB file (specified in valueClobFile) contents.
- Default: 'UTF-8'
-
Note: used only when valueClobFile attribute is specified, ignored otherwise.
-
-
\ No newline at end of file
diff --git a/_includes/subnav_blog.md b/_includes/subnav_blog.md
deleted file mode 100644
index 07aa0ec04..000000000
--- a/_includes/subnav_blog.md
+++ /dev/null
@@ -1,7 +0,0 @@
-
- {% include components/buttons/cta.html ctaText="Visit the Expert Exchange" ctaHref="https://download.liquibase.org/expert-exchange" %}
-
-
-
- {% include components/top-nav.html %}
-
-
-
-
- {% assign subnavPrefix = "subnav" %}
- {% assign returnFileName = subnavPrefix %}
- {% assign subRoutes = page.path | split:'/' %}
-
- {% if subRoutes.size > 1 %}
- {% for route in subRoutes %}
- {% if forloop.last %}
-
- {% else %}
- {% capture returnFileName %}{{returnFileName}}_{{route}}{% endcapture %}
- {% endif %}
- {% endfor %}
- {% capture returnFileName %}{{returnFileName}}.md{% endcapture %}
- {% else %}
- {% capture returnFileName %}{{returnFileName}}_main.md{% endcapture %}
- {% endif %}
-
- {% if page.subnav %}
- {% assign navPage = page.subnav %}
- {% else %}
- {% assign navPage = returnFileName %}
- {% endif %}
-
- {% case navPage %}
- {% when "subnav_main.md" %}
- {% include subnav_main.md %}
- {% when "subnav_documentation.md" %}
- {% include subnav_documentation.md %}
- {% when "subnav_documentation_changes.md" %}
- {% include subnav_documentation_changes.md %}
- {% when "subnav_documentation_sdk.md" %}
- {% include subnav_documentation_sdk.md %}
- {% when "subnav_development.md" %}
- {% include subnav_development.md %}
- {% when "subnav_community.md" %}
- {% include subnav_community.md %}
- {% when "subnav_blog.md" %}
- {% include subnav_blog.md %}
- {% when "subnav_quickstart.md" %}
- {% include subnav_quickstart.md %}
- {% when "subnav_maven.md" %}
- {% include subnav_maven.md %}
- {% when "subnav_tutorials.md" %}
- {% include subnav_tutorials.md %}
- {% else %}
- Unknown Nav {{navPage}}
- {% endcase %}
-
-
- {% include components/search/gcse-search.html isSideNav="true" %}
-
- {% include components/news-block.html %}
-
- {% if page.includeDaticalBox %}
-
-
-
-
-
- {% endif %}
-
-
-
-
-
- {% if page.date %}
-
-
{{page.title}}
-
-
POSTED {{page.date | date_to_string}} by
- Nathan Voxland
-
- {% endif %}
-
- {{content}}
-
-
-
diff --git a/_posts/2007-05-31-welcome-to-the-liquibase-blog.md b/_posts/2007-05-31-welcome-to-the-liquibase-blog.md
deleted file mode 100644
index 6d9856c74..000000000
--- a/_posts/2007-05-31-welcome-to-the-liquibase-blog.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Welcome to the Liquibase Blog
----
-
-# Welcome to the Liquibase Blog
-
-We are starting the Liquibase blog for several reasons:
-
-Partly, it will be a place to announce new features and releases of Liquibase.
-
-Primarily, however, it will be a place to comment on agile database development in general, best practices, and pitfalls to avoid.
diff --git a/_posts/2007-06-01-the-road-to-liquibase-10-and-beyond.md b/_posts/2007-06-01-the-road-to-liquibase-10-and-beyond.md
deleted file mode 100644
index 2bcfdb954..000000000
--- a/_posts/2007-06-01-the-road-to-liquibase-10-and-beyond.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: The Road to Liquibase 1.0 and Beyond
----
-
-# The Road to Liquibase 1.0 and Beyond
-
-There is a lot going on in Liquibase-land right now.
-
-We are finishing up code and documentation clean-up of the Liquibase migrator and hope to have an initial release candidate available by the middle of June.
-
-As long as no major bugs are found, we expect 1.0 to be released by the end of June.
-
-Concurrent to the final code reviews and bug fixes leading up to 1.0, we have started on a SQuirreL plug-in for automatic creation of changelog files. There is no target date yet for an initial release, but it will probably be post 1.0. If there is anyone interested in working on a plug-in for other IDEs, just let us know.
-
-We are also already looking at features to include in a 1.1 release. Items currently on the top of the list include an additional changeSet attribute for specifying the types of databases that it should be run against as well as support for additional databases (Sybase, DB2, Derby, perhaps more).
diff --git a/_posts/2007-06-05-unit-testing-the-database-access-layer.md b/_posts/2007-06-05-unit-testing-the-database-access-layer.md
deleted file mode 100644
index b965ce9ee..000000000
--- a/_posts/2007-06-05-unit-testing-the-database-access-layer.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Unit Testing the Database Access Layer
----
-
-# Unit Testing the Database Access Layer
-
-### The Problem
-
-Writing unit tests for code that accesses a database is a difficult problem, and it's one I've struggled with for several years. The problems come down to a balancing act between several (often competing) requirements:
-
-1. The unit test must not not break due to changes outside the class under test.
-1. The unit test must not break due to code refactoring that doesn't break functionality.
-1. The unit test must run very fast.
-1. The unit test must remain valid through database refactorings.
-1. The unit test must fail if the code doesn't function correctly.
-
-I've tried several approaches in the past and was unsatisfied with them:
-
-### Mock the Database Connection
-
-This is the most "pure" unit testing approach because it completely isolates the class under test from all external dependencies.
-
- Connection conn = createMock(Connection.class);
- Statement statement = createMock(Statement.class);
- expect(conn.createStatement()).andReturn(statement);
- expect(statement.execute("SELECT ID FROM PERSON;")).andStubReturn(true);
- statement.close();
- expectLastCall();
- replay(conn);
- replay(statement);
-
- ClassUnderTest classUnderTest = new ClassUnderTest ();
- classUnderTest .findPersonIds();
-
- verify(conn);
- verify(statement);
-
-The advantages to mocking the database connection is that the tests run fast and don't change to due to creating of other unit tests.
-
-In practice, however, I've found these tests to be more or less worthless. They (like most mock tests) really just test the implementation of the method, not the behavior of the method, and therefore often fail due to code refactoring. The biggest problem, however, is that the access to the database is really the whole point of the method and there are so many ways that can fail.
-
-I would argue, that really the method is implemented as SQL with a Java wrapper around it and in the mock unit test, only the Java code is really tested--the SQL is often just cut and pasted from what is in the method.
-
-Throw in changes to the database over the life of the project (the "person" table name changes to "employee") and you end up with tests that pass, but don't really tell you if your code will work.
-
-### Create Test Data Sets For Each Test
-
-The obvious response to the problems with mock database tests is to have your tests access an actual database. This method will create tests that actually fail if your SQL is wrong or your database schema changes without a corresponding code update, but brings with it its own difficulties, primarily with keeping the database in a known state. There are tools available such as DbUnit and Unitils to help with the test-data management, but these have disadvantages.
-
-The main problem is that the way the test data is stored, it is very dependent on the exact schema when it was created, and if your database structure changes your test data can no longer be inserted and your tests are now worthless. For example, if your test is created with test data that inserts rows into a "person" table, but later that table is renamed to "employee", your insert statements will no longer execute. Depending on the schema changes, you may be able to recover your test data with a search and replace, but often the changes are too much and it has been long enough since you wrote the test that you don't remember exactly what was supposed to be in the data.
-
-Additionally, the data is inserted as part of the setup method for each test. Accessing databases in Unit tests slows them down considerably already, we should work to minimize any calls to the database that we have to do.
-
-### Manage Test Data With All Other Database Changes
-
-To solve the problem of keeping test data definitions from getting out of sync with the schema, you need to have your test data built up along with your database so it will be modified by database refactoring that were made after it was initially created. For example, here is a database change script:
-
-1. create table person
-1. insert row into person `test data`
-1. insert row into person `test data`
-1. rename table person to employee
-
-By including the test data with your database changes, the data is automatically kept up in the same way the production data would be. Using this technique over the dataset per method also has the advantage of performing better because the data is only inserted once, but it has the disadvantage that you need to handle all the test data that any method would want in one place.
-To facilitate this technique, I built the idea of execution contexts into Liquibase so you can mark the test data changes and only apply them in environments where you run unit tests. So far I have been happy with the results. The tests fail when there is a differences between the database schema and what the code is expecting or when there is a bug in my SQL and I haven't lost any tests due to database refactorings.
-
-The tests don't run as fast as mock connection tests would, but they aren't prohibitively slow. We have over 1000 unit tests in one project that all run in about a minute. It would be better if they would all run in 10 seconds, but what good are fast tests that don't actually test what's important? Just remember to mock the (already tested) data access layer in higher layers of your code so you don't take the database performance hit any more than you need to.
-
-With this technique, you need to always remember that your test data set will evolve over time and write your tests accordingly, but how to do that will be covered in a later blog posting.
-
diff --git a/_posts/2007-06-07-building-database-tests-that-dont-break.md b/_posts/2007-06-07-building-database-tests-that-dont-break.md
deleted file mode 100644
index 6ddffa207..000000000
--- a/_posts/2007-06-07-building-database-tests-that-dont-break.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Building Database Tests that Don't Break
----
-# Building Database Tests that Don't Break
-
-As I discussed in Unit Testing the Database, a difficulty you run into when using a shared dataset for unit tests is making sure you write your test in such a way that changes to the dataset will not break older tests.
-
-Note: depending on the database access framework you use, you will actually access the database through a Connection, EntityManager, Session, PersistenceManager etc. I'll use the term "Connection" generically for any of these access types because the same pattern applies to them all.
-
-###Don't Rely on Particular Data###
-
-The following is an example of a bad test that will break when the dataset changes:
-
-
- public void testFindActive() {
- Collection returnSet = new PersonDAO(connection).findActive();
- assertEquals(5, returnSet.size());
- }
-
-When you first write the above test, it will work fine because you have know your data set has 5 person rows in it. However, when you get to the next test and realize you need more test data and add a new person row, the testFindActive() method will suddenly fail when the method being tested isn't actually broken.
-
-What I have found to be the best way of writing better tests is to create a framework that lets you describe what type of rows you expect your method to return. Here is a code example:
-
- public void testFindActive() {
- assertDataCorrect("Did not return active people correctly",
- new DataComparator(entityManager, Person.class) {
- public boolean include(Person person) {
- return person.isActive();
- }
- }
- }
-
-There are two advantages to this method of testing:
-
-1. It doesn't break if person rows are added or removed
-1. The test better documents the intent of the isActive() method
-1. Since you are describing your filter via normal object methods, the test will stay up to date as you refactor your code/
-
-Of course, you need to have an implementation of assertDataCorrect(). Unfortunately, although it is fairly straightforward to implement, how you actually implement it varies depending on your database access framework. Here is a pseudo-code sample to get you started:
-
-
- public abstract class DataTestCase extends TestCase {
- assertDataCorrect(String message,
- DataComparator comparator, Collection
- collectionToTest) {
- assertNotNull("Collection to test was null, poor test", collectionToTest);
- assertTrue("Collection to test was empty, poor test", collectionToTest.size() > 1);
-
- List allObjects = comparator.getEntityManager
- .createQuery("from " + comparator.getEntityClass().getName());
-
- int matchingObjects = 0;
- List filteredObjectsFromDB = filterObjects(comparator, allObjects);
- for (Object objectFromDB : filteredObjectsFromDB) {
- matchingObjects++;
- if (!collectionToTest.contains(object)) {
- fail ("Expected object '"+object.toString()+"' not found in collection");
- }
- }
- assertTrue("Expected "+matchingObjects
- +" objects, passed collection was "+collectionToTest.size(),
- matchingObjects == collectionToTest.size());
- }
- }
-
-Some notes on the above implementation:
-
-1. The class extends TestCase so as long as all your database tests extends the new DatabaseTestCase you will always have access to the new assertions.
-1. If the passed collection is null or empty, the test fails. The reason for this is because if your query is returning nothing from the database, you don't really know if it is filtered down correctly. It could be working correctly, or it could be you have a typo in your filter that will always make it return no results.
-1. The assert function selects out all rows from the database and compares them to the returned objects. If you have a lot of rows, this will be a very poor-performing test. In practice, your test dataset will normally not grow so large this will become a problem, but it is something to keep in mind if you ever think about running your test suite against a copy of production data.
-
-Eventually, I hope to create a database unit testing library that better encapsulates this logic, but have not had the time yet. If there is anyone who would like to volunteer to help out with creating one, please contact me at nathan@voxland.net.
-
-### Start a transaction in your setUp() method and roll it back in your tearDown() method
-
-By running your test in a transaction, you ensure that (normally) whatever your code under test does to the database will have no lasting affect and will not cause later tests to fail. This is a simple extension of the unit testing principal of not assuming your tests will run in a particular order and to have no side effect of your tests.
-
-If your code under test attempts to start and commit transactions, you may need to create a wrapper connection around the actual connection that intercepts calls to start and end transactions and simply logs that they happened. That way you can test that the commit you expected actually happened and still actually roll back the database in your tearDown() method.
-
-The thing to watch out for is auto-committing code in your class under test. For example, if your tested logic creates a new table, many databases will auto-commit the transaction. In these cases, you will need to manually undo the changes in a finally block in your test so you still follow the "no side-effect" rule.
diff --git a/_posts/2007-06-08-liquibase-10-rc1-released.md b/_posts/2007-06-08-liquibase-10-rc1-released.md
deleted file mode 100644
index c484d88de..000000000
--- a/_posts/2007-06-08-liquibase-10-rc1-released.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.0 RC1 Released
----
-# Liquibase 1.0 RC1 Released
-
-Liquibase 1.0 RC1 has been released. Changes since 0.9.1 are primarily code refactoring to make sure it is a clean code base to work with post-1.0. The only new feature is a batch and shell script for easier running of the command line migrator. There were also the usual documentation improvements and bug fixes.
-
-Please report all bugs you find with the release candidate so they can be addressed in the 1.0 release, particularly in the Maven support. Unless there are show-stopper bugs found, the final 1.0 release should be out in two weeks or less.
-
diff --git a/_posts/2007-06-19-liquibase-10-rc2-released.md b/_posts/2007-06-19-liquibase-10-rc2-released.md
deleted file mode 100644
index 6d037e634..000000000
--- a/_posts/2007-06-19-liquibase-10-rc2-released.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.0 RC2 Released
----
-# Liquibase 1.0 RC2 Released
-
-Liquibase 1.0 RC2 has been released. Changes since RC2 are primarily minor bug fixes.
-
-The reason for having a RC2 rather than 1.0 final is that we changed exceptions thrown by some methods and want to make sure that change does not cause any unexpected problems.
-
-Please report all bugs you find with the release candidate so they can be addressed in the 1.0 release, particularly in the Maven support.
-
-Unless there are show-stopper bugs found, the final 1.0 release should be out next week.
-
diff --git a/_posts/2007-06-20-the-problem-with-database-diffs.md b/_posts/2007-06-20-the-problem-with-database-diffs.md
deleted file mode 100644
index 88c0d09f6..000000000
--- a/_posts/2007-06-20-the-problem-with-database-diffs.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: The Problem with Database Diffs
----
-# The Problem with Database Diffs
-
-When talking about how Liquibase works, I'm often asked "Why not just do a database diff to know what changes need to be applied to a new database?"
-
-There are advantages to the database diff technique compared to Liquibase's method of tracking changes, mainly related to not relying on developers to remember to document the changes they made. You simply have everyone make whatever changes they want to the dev database and let the diff tool sort it out.
-
-There are two fundamental flaw with diff tools, however. The first is is that while they do a good job of showing what the differences are *syntactically*, they don't understand the *semantics* of the changes. For example, if you rename a column from "fname" to "firstname", a diff will show you that there is a "fname" column that needs to be dropped and a "firstname" column that needs to be be added. If you follow these suggestions, you will end up with a database that is structured correctly, but you will lose your valuable data when the changes are applied to an existing production system. You need to not just understand *what* the structural differences are, you also need to understand *why* they are.
-
-The second flaw is that it is impossible to diff the data so you find inserts, updates, and deletes that must be applied for the system to work correctly. These data changes can range from additional lookup table values to copying data in a de-normalizing process and can be just as important as the structural changes. Theoretically, a diff tool could also check for new, updated, and missing data between database, but in practice this cannot work for two reasons:
-
-1. Performance. As your data set grows, the amount of information to compare grows until it is unmanageable.
-1. Changing Data. During development, test data is often added to the development database that shouldn't be copied into other databases. Also, new data may be added to testing and production databases that should not be deleted just because it doesn't exist in the development database.
-
-If you track your data changes along with your structural changes during development, however, you can be certain that they will be applied correctly down the road.
-
-In the end, I feel that the problems associated with a diff tool outweighs the convenience and simplicity they offer. While they can have great value as a "did all the changes get stored in the change log correctly" safeguard, it should not be relied upon as your primary means of tracking database changes.
diff --git a/_posts/2007-06-22-managing-change-logs.md b/_posts/2007-06-22-managing-change-logs.md
deleted file mode 100644
index 434122381..000000000
--- a/_posts/2007-06-22-managing-change-logs.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Managing Change Logs
----
-
-# Managing Change Logs
-
-While you can include all your change sets in one giant change log, there are many good reasons to split them up. While there are many ways to divide your change logs, the best strategy I have found is to create a change log per major java package that contains data access code. This approach has several advantages:
-
-#### Easy to Know Where to Add (and Look For) Database Changes
-
-If you are making a database change due to code in a package, you know exactly where to put the change.
-
-#### Makes Code-Reuse and Code-Repackaging Easier
-
-Since packages are often used as a logical code unit, the code to manage database changes can be moved and re-used along with the java code.
-
-#### Keeps Database Changes Closer to the Code
-
-You don't need to go hunt through your file navigator as you switch between adding required databases changes and making the corresponding code changes.
-
-#### Fewer File Conflicts
-
-On multi-developer teams, the database change logs are a shared resource with many individuals editing them. Like any version controlled file, the more developers and the more branches that touch a file, the more chances for problems. Breaking up a change log into multiple files limits the changes and extent of merge issues.
-
-There are, of course, other ways to break up your change log files including one change log per project and one change log per table. Depending on your requirements, these or other strategies may work better for you. The important thing is to find what works best for you.
diff --git a/_posts/2007-06-25-liquibase-10-released.md b/_posts/2007-06-25-liquibase-10-released.md
deleted file mode 100644
index fadf48e93..000000000
--- a/_posts/2007-06-25-liquibase-10-released.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.0 Released
----
-# Liquibase 1.0 Released
-
-The Liquibase team is proud to announce version 1.0. Liquibase is an open source (LGPL) java-based tool for managing database changes and refactorings. It has been under active development for over a year and supports many features including:
-
-
-- Change tracking format that supports multiple developers and code branches
-- Thirty built-in refactorings including "Merge Columns" and "Add Lookup Table"
-- Can execute updates directly, or save SQL for review by DBAs
-- Can roll back databases to earlier versions based on dates, tags, or number of changes
-- Database independent. Currently supports MySQL, PostgreSQL, Oracle, and MSSQL with additional databases planned for version 1.1.
-- Can be executed as an Ant task, a Maven Plug-in, as a Servlet Listener, or though a command-line program
-- Changes can be tagged with "contexts" so not all changes need to be applied to all environments
-- Uses a distributed locking system to protect against machines upgrading the same database at the same time
-- Extensive documentation including a quick-start guide and manual
-
-As a database change tracking tool, Liquibase is useful for any project with a database, but is especially useful in an agile environment due to the large number of changes that are generated throughout the project's lifecycle.
-
-There are many post-1.0 features planned, including support for additional databases (DB2, Sybase, Derby and HSQL are already implemented in the 1.1 branch), a database-refactoring IDE plug-ins, additional refactorings, a database diff tool, and more.
-
-We would like to thank everyone who helped us get to the point we are at today.
-
diff --git a/_posts/2007-06-25-the-problem-with-rails-active-migrations.md b/_posts/2007-06-25-the-problem-with-rails-active-migrations.md
deleted file mode 100644
index 797747a1e..000000000
--- a/_posts/2007-06-25-the-problem-with-rails-active-migrations.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: The Problem with Rails Active Migrations
----
-# The Problem with Rails Active Migrations
-
-Rails Active Migration is nice for its simplicity, but in non-trivial projects, it quickly falls apart due to limitations it has regarding multiple developers and/or branches. It's a well known problem
-
-The fundamental problem is that Rails tracks the "database version" as a single incrementing integer. That works fine when only one developer is adding migrations and when there is only one branch. When you add developers and branches, however, you quickly run into problems with duplicated version numbers, and missed migrations because the production "database version" is higher than a newly merged in migration.
-
-The reason this is a problem is because there the reliance on a the "database version" concept. While there may be a logical database version that you can think about, really the state of the database is simply the set of all the applied migrations. Think of a file in source control. The source control system may generate "version" numbers for reference, but it doesn't use them to decide what should be merged in. When you say "merge the "1_1" branch into trunk, it simply takes all the changes in the "1_1" branch and applies the same changes to trunk, regardless of whether the file in trunk has a higher "version number" or not. The same logic needs to be applied to database updates.
-
-There are attempts to solve the situation in the Ruby community. The work-around solution works by naming each change by a timestamp and storing all the executed changes in the schema_migrations table. While it is a step in the right direction, if you need to re-order the execution of changes after a commit by multiple developers or after a merge it can be difficult. Hopefully a good solution to the problem is created soon, or we will have to develop a port of Liquibase for Ruby :)
-
diff --git a/_posts/2007-07-03-sox-compliance-and-database-refactoring.md b/_posts/2007-07-03-sox-compliance-and-database-refactoring.md
deleted file mode 100644
index 126a1a25a..000000000
--- a/_posts/2007-07-03-sox-compliance-and-database-refactoring.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: SOX Compliance and Database Refactoring
----
-
-
-# SOX compliance and Database Refactoring
-
-Managing, tracking, and applying database changes is difficult, especially in an agile database environment where there are many changes made throughout a project's life cycle. Even with a tool like Liquibase, It takes a lot of discipline to apply your database changes in a consistent and traceable manner.
-
-For projects that need to deal with SOX-compliant releases the process is even more difficult because your release documentation needs to include not only how to update your database, but also how to roll back in case of a problem with the release.
-
-It was to address this problem that we added automatic rollback support to Liquibase. For each changeSet in your change log file, Liquibase can (usually) generate rollback SQL. For changes that cannot be automatically undone (drop table, insert data, etc.), or if you want to override the default rollback method, you can specify a tag containing the correct SQL. This method of generating rollback commands works well because for most cases you don't have to do anything, and when you do have to specify rollback SQL, it is stored along side the original change.
-
-To control the generation of generating SQL for updating a database and for rolling it back, see the command line migrator documentation.
-
diff --git a/_posts/2007-07-06-liquibase-101-released.md b/_posts/2007-07-06-liquibase-101-released.md
deleted file mode 100644
index 2baec8036..000000000
--- a/_posts/2007-07-06-liquibase-101-released.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.0.1 Released
----
-# Liquibase 1.0.1 Released
-
-1.0.1 is a minor bug fix release that addresses an issue with null values in the defaultValue attribute being quoted.
diff --git a/_posts/2007-07-06-start-with-simple-evolutionary-database-design.md b/_posts/2007-07-06-start-with-simple-evolutionary-database-design.md
deleted file mode 100644
index 1fac7e961..000000000
--- a/_posts/2007-07-06-start-with-simple-evolutionary-database-design.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Start with Simple Evolutionary Database Design
----
-# Start with Simple Evolutionary Database Design
-
-Reg Developer in the UK recently posted an interview with Scott Ambler about database refactoring at http://www.regdeveloper.co.uk/2007/07/04/evolutionary_database_design/.
-
-In the interview, he discusses questions developers and DBAs often have when first approaching evolutionary database design (EDD). The two main points he covers are:
-
-1. Having both developers and DBAs involved in the database design process is an improvement over "traditional" waterfall-style databases designed only by the DBA.
-2. If you make your schema changes with triggers and views correctly, you can have a "transition window" that will allow you to make your changes without breaking existing systems that use the database.
-
-While I agree with both these points, I worry about his focus on "transition window" database refactoring methods. There is certainly value in being able to provide these windows for databases that have many independent systems depending on them, but I think that for the vast majority of projects it makes database refactoring seem too difficult to even attempt.
-
-I would propose that more focus needs to be placed on the simpler aspect of EDD: databases that are specific to a single system or set of related systems that are all managed and updated in a frequent, agile manner. These are the teams most likely to adopt an EDD process and there is still a lot of work to get them the tools they need to work efficiently.
-
-In the interview, Scott says that "right now we're at the beginning of the adoption curve" in regards to EDD and I agree with that. So--for now--let's focus on the needs of the majority of those early adopters.
-
-I see the tools and practices required to do EDD efficiently as a spectrum that range from a single-project database with no DBA, through a set of related projects with a part time DBA involved, to a database that supports a large set of independent systems that is under the constant care of a DBA. "Transition Window" methods of database refactoring work great for the high end of the spectrum and I don't think it should be ignored because it is important to know that a process can scale.
-
-For now, however, we need to start a the simple end and build a strong foundation of tools and techniques before working our way up the stack to the top. There is the start of the required tools in the form of DBUnit for unit testing and Liquibase for managing refactorings, but there is still large holes including IDE support for refactorings, best practices and pattern catalogs for database testing, and more.
\ No newline at end of file
diff --git a/_posts/2007-07-23-liquibase-11-released.md b/_posts/2007-07-23-liquibase-11-released.md
deleted file mode 100644
index 439a1b8b7..000000000
--- a/_posts/2007-07-23-liquibase-11-released.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.1 Released
----
-# Liquibase 1.1 Released
-
-Liquibase 1.1 has been released. Major new features include:
-
-- Support for additional databases: DB2, Derby, Sybase (not fully tested), and HSQL
-
-- Support for "unsupported" databases
-
-- Database Diff Tool
-
-- Database Creation Script Generator
-
-- new DBMS attribute on change set tag that allows you to specify what databases to run the change set against
-
-- "verify" command that checks for change log problems without attempting to execute any
-
-- "status" command that shows information on unrun change sets
-
-- Handle date/time and numeric values better on inserts and setting default values
-
-- Bug Fixes
-
-Upgrading is simply a matter of replacing the liquibase.jar file. To take advantage of newer change log features, change your XSD declaration to:
-
-
-
-Download Liquibase 1.1
-
diff --git a/_posts/2007-07-24-liquibase-111-released.md b/_posts/2007-07-24-liquibase-111-released.md
deleted file mode 100644
index 7fac934f4..000000000
--- a/_posts/2007-07-24-liquibase-111-released.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.1.1 Released
----
-# Liquibase 1.1.1 Released
-
-Liquibase 1.1.1 has been released to address issues found with the diff tool in the 1.1 version.
diff --git a/_posts/2007-07-24-revenge-of-the-mock-tests.md b/_posts/2007-07-24-revenge-of-the-mock-tests.md
deleted file mode 100644
index 2bbd7027e..000000000
--- a/_posts/2007-07-24-revenge-of-the-mock-tests.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Revenge of the Mock Tests
----
-# Revenge of the Mock Tests
-
-If you didn't see, version 1.1.1 of Liquibase was released the day after 1.1 because of problems reported by users with the new diff tool.
-
-Now, we could simply say "it's a new feature, you should expect bugs", but they were pretty obvious ones that should have been caught by simply executing the diff tool against all our supported databases. A simple unit test or two that actually ran the diff tool exposed the bugs and they were easy to catch.
-
-Why weren't those tests wrote before the 1.1 release? It was because I was testing with a mock database connection which didn't capture all the idiosyncrasies of different databases. The tests were there, and the coverage was there, but there were still bugs because of limitations in the (mock) abstraction layer.
-
-The lesson to be learned is that when writing database access level code, never use a mock database connection.
diff --git a/_posts/2007-08-22-liquibase-ide-and-eclipse-plug-in-05.md b/_posts/2007-08-22-liquibase-ide-and-eclipse-plug-in-05.md
deleted file mode 100644
index 5fe1bdeb7..000000000
--- a/_posts/2007-08-22-liquibase-ide-and-eclipse-plug-in-05.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase IDE and Eclipse Plugin
----
-# Liquibase IDE and Eclipse Plugin 0.5
-
-I have released the initial version of a Liquibase IDE. The idea behind it is to do for database refactoring what refactoring tools like IntelliJ and Eclipse have done for code refactoring.
-
-The initial release is intended primarily to look for feedback from users and from people with experience writing Eclipse plug-ins and RCP applications.
-
-Current functionality includes:
-
-- Applying refactorings to a database and having them stored in a change log file
-- Executing a change log file against a database
-- Tagging a database
-
-While the functionality may be a bit rough around the edges (not a lot of validation, will probably get an error message or two) it is functionally complete for creating and applying changes.
-
-Plans for the final 1.0 release include interfaces for rollbacks and rollback-management, database diffs, and more.
-
-If you would like to help out with the development of the IDE/plug-in or would like to create a similar plug-in for your favorite IDE, please let me know. It is a very large undertaking and I could use some help :)
-
diff --git a/_posts/2007-08-28-liquibase-12-released.md b/_posts/2007-08-28-liquibase-12-released.md
deleted file mode 100644
index 700a4f2ec..000000000
--- a/_posts/2007-08-28-liquibase-12-released.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.2 Released
----
-# Liquibase 1.2 Released
-
-Liquibase 1.2 has been released. Major features include:
-
-- Support for H2 database
-- Support for InterSystems Cache database
-- Support for `` change
-- Improved error messages
-- `` tag can contain a `` tag
-- Change log file references can be absolute
-- SQL in `` tag can be ; or 'go' delimited
-- New clearCheckSums command in command line migrator
-
-- Support for version 0.5 of the Liquibase IDE and Eclipse Plugin
-
-Many bugs have been fixed as well, including:
-
-- Sybase support fixes
-- Handle --defaultsFile correctly
-- Handle command line parameters correctly on Windows systems
-- Other bug fixes
-
-Upgrading is simply a matter of replacing the liquibase.jar file. To take advantage of newer change log features, change your XSD declaration to:
-
-
-
-Download Liquibase 1.2
-
diff --git a/_posts/2007-08-31-liquibase-121-released.md b/_posts/2007-08-31-liquibase-121-released.md
deleted file mode 100644
index 869535c4c..000000000
--- a/_posts/2007-08-31-liquibase-121-released.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.2.1 Released
----
-# Liquibase 1.2.1 Released
-
-Liquibase 1.2.1 is a minor bugfix release to address the following issues:
-
-- Ordering of default values and not null clauses on some databases including Oracle
-
-- Sequences were not included in the generateChangeLog output
-The update is available on the download page
-
diff --git a/_posts/2007-08-31-liquibase-ide-06-released.md b/_posts/2007-08-31-liquibase-ide-06-released.md
deleted file mode 100644
index 071029879..000000000
--- a/_posts/2007-08-31-liquibase-ide-06-released.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase IDE 0.6 Released
----
-# Liquibase IDE 0.6 Released
-
-Version 0.6 of the Liquibase IDE and the Eclipse Plug-in have been released. This version does not add new functionality, but does fix a showstopper bug that prevented the creation of change log files.
-
-Information on downloading the new version is available on the download page.
-
diff --git a/_posts/2007-09-27-liquibase-13-released.md b/_posts/2007-09-27-liquibase-13-released.md
deleted file mode 100644
index e9b5b9fc2..000000000
--- a/_posts/2007-09-27-liquibase-13-released.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.3 Released
----
-# Liquibase 1.3 Released
-
-Liquibase 1.3 has been released. Major features include:
-
-- Added `custom` change
-- Added `executeCommand` change
-- Added `createProcedure` change
-- Added sqlCheck precondition
-- Added dbdoc documentation generator
-- Added Spring migrator
-- Added tablespace support to createTable, createIndex, addPrimaryKey, and addUniqueConstraint
-- Added defaultCascade attribute to addForeignKeyConstraint
-- Can have multiple comma-separated contexts per change set
-- Database Diff checks column types and nullability
-- DiffChangeLog will write to a file specified with the `--changeLog` flag
-- Database Diff checks views
-- Added ability to control strippig of comments and splitting of lines in tag
-- Added Postgres support to auto-increment related refactorings
-
-Many bugs have been fixed as well, including:
-
-- Restored Java 6 Support
-- Absolute path changelogs are handled correctly on Windows
-- Other bug fixes
-
-Upgrading is simply a matter of replacing the liquibase.jar file. To take advantage of newer change log features, change your XSD declaration to:
-
-
-
-Download Liquibase 1.3 from: https://download.liquibase.org/download-community/
-
diff --git a/_posts/2007-10-08-liquibase-grails-plugin.md b/_posts/2007-10-08-liquibase-grails-plugin.md
deleted file mode 100644
index 8fa3c9872..000000000
--- a/_posts/2007-10-08-liquibase-grails-plugin.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Grails Plugin
----
-# Liquibase Grails Plugin
-
-The newest version of Liquibase now has a Grails plug-in available. To install the plug-in, simply run "grails install-plugin liquibase".
-
-Full documentation on the Grails plug-in is available at https://github.com/liquibase/grails-liquibase
-
-
diff --git a/_posts/2007-11-14-initial-liquibase-intellij-idea-plug-in-released.md b/_posts/2007-11-14-initial-liquibase-intellij-idea-plug-in-released.md
deleted file mode 100644
index 2c5917d50..000000000
--- a/_posts/2007-11-14-initial-liquibase-intellij-idea-plug-in-released.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Initial Liquibase IntelliJ IDEA Plugin Released
----
-# Initial Liquibase IntelliJ IDEA Plugin Released
-
-For you IntelliJ IDEA users out there, there is now a Liquibase plugin available through the Intellij plug-in manager.
-
-- Like the Eclipse plugin, the IntelliJ plugin allows you to refactor your database like you refactor code using a "Refactor" context menu on database objects. These changes are automatically saved to a change log file.
-
-- A "Liquibase" context menu on the database explorer allows you to migrate your database, roll back changes, generate documentation, and more.
-- Additional refactoring and better documentation will be added in upcoming releases.
-- As usual, please let us know if you have any questions or suggestions.
diff --git a/_posts/2007-11-19-liquibase-core-140-released.md b/_posts/2007-11-19-liquibase-core-140-released.md
deleted file mode 100644
index b49cc1f76..000000000
--- a/_posts/2007-11-19-liquibase-core-140-released.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Core 1.4.0 Released
----
-# Liquibase Core 1.4.0 Released
-
-Liquibase 1.4.0 has been released. Major features include:
-
-- IntelliJ Plug-in Support
-- Added support for specifying schemas in change log
-- MaxDB/SAPDB Support
-- Refactored Code
-- Can specify data types as `java.sql.Types.*`
-- Support for composite foreign keys
-- Improved Maven support
-- Bug Fixes
-
-Upgrading is simply a matter of replacing the liquibase.jar file. To take advantage of newer change log features, change your XSD declaration to:
-
-
-
-Download Liquibase 1.4 from: https://download.liquibase.org/download-community/
-
diff --git a/_posts/2007-11-20-liquibase-at-javaone-cross-your-fingers.md b/_posts/2007-11-20-liquibase-at-javaone-cross-your-fingers.md
deleted file mode 100644
index fde04149d..000000000
--- a/_posts/2007-11-20-liquibase-at-javaone-cross-your-fingers.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase at JavaOne
----
-# Liquibase at JavaOne
-
-Cross your fingers!
-
-I submitted a JavaOne 2008 session into the call for papers. I went for a combination of Liquibase usage and general database change management. Let's hope I'm selected!
diff --git a/_posts/2007-11-21-liquibase-overview-videos.md b/_posts/2007-11-21-liquibase-overview-videos.md
deleted file mode 100644
index f3cfc1f79..000000000
--- a/_posts/2007-11-21-liquibase-overview-videos.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Overview Videos
----
-# Liquibase Overview Videos
-
-I have made two Liquibase overview videos available to help explain what Liquibase is and some of its capabilities. One is very brief (6 minutes) while the other is a more in-depth 30 minute video.
-
-I'm planning on adding additional videos in the future. If you have a suggestion on a topic you would like covered, please let us know.
-
-
diff --git a/_posts/2007-11-30-liquibase-141-core-intellij-and-grails.md b/_posts/2007-11-30-liquibase-141-core-intellij-and-grails.md
deleted file mode 100644
index 6f1aa14e4..000000000
--- a/_posts/2007-11-30-liquibase-141-core-intellij-and-grails.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.4.1
----
-# Liquibase 1.4.1
-
-Liquibase Core 1.4.1 has been released. This is primarily a bug fix release.
-
-Upgrading is simply a matter of replacing the liquibase.jar file.
-
-Download Liquibase Core 1.4.1 from:
-
-https://download.liquibase.org/download-community/
-
-The IntelliJ plug-in has also been updated to support 1.4.1. It can be installed or updated through the IntelliJ plug-in manager.
-
-The Grails plug-in has also been updated to support 1.4.1. It is installed through the standard grails plug-in infrastructure.
-
-As usual, let me know of any issues or suggestions you have questions.
-
diff --git a/_posts/2007-12-06-official-maven-support.md b/_posts/2007-12-06-official-maven-support.md
deleted file mode 100644
index 9828a4de2..000000000
--- a/_posts/2007-12-06-official-maven-support.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Official Maven Support
----
-# Official Maven Support
-
-Thanks to Peter Murray, we now have working Maven support and good documentation.
-
-See https://mvnrepository.com/artifact/org.liquibase/liquibase-core for more information.
-
diff --git a/_posts/2007-12-19-japanese-documentation-complete.md b/_posts/2007-12-19-japanese-documentation-complete.md
deleted file mode 100644
index e689b92fc..000000000
--- a/_posts/2007-12-19-japanese-documentation-complete.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Japanese Documentation Complete
----
-# Japanese Documentation Complete
-
-I would like to thank Yasuo Honda for all his hard work on the Japanese translation of the Liquibase documentation. He was also a great help in determining the best wiki tool to use to support translations.
-
-If you are interested in assisting with translating the Liquibase documentation, feel free to edit the site wiki directly, or contact us.
-
diff --git a/_posts/2008-01-29-liquibase-core-150-released.md b/_posts/2008-01-29-liquibase-core-150-released.md
deleted file mode 100644
index 22301f7e7..000000000
--- a/_posts/2008-01-29-liquibase-core-150-released.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.5.0 Released
----
-# Liquibase Core 1.5.0 Released
-
-Liquibase Core 1.5.0 is now available for download from https://download.liquibase.org/download-community/
-
-1.5.0 includes a major refactoring which should not affect most users except for the following items:
-
-#### BREAKING CHANGES
-
-- *Servlet Migrator:* The web.xml parameter names have changed. See https://www.liquibase.org/documentation/servlet_listener.html for more information.
-
-- If you used the "database.migrator.should.run", it is must now be changed to "liquibase.should.run"
-
-- If you have extended or embedded Liquibase classes or calls directly in your code, changes will be necessary.
-
-
-
-#### BACKWARDS-COMPATIBLE CHANGES
-
-
-
-- *Servlet Migrator:* The classes to reference in web.xml have changed to liquibase.servlet.LiquibaseStatusServlet and liquibase.servlet.LiquibaseServletListener. The old classes are now simply subclasses of the new and are deprecated so they should work.
-
-- *Spring Migrator:* The class to reference in your spring config has changed to liquibase.spring.SpringLiquibase. The old class still exists as a subclass of the new so existing configurations should continue to work.
-
-- *Command Line:* The "migrate" command has been changed to "update".
-"migrate" is now an alias for "update" so existing calls should continue to work
-
-
-#### ENHANCEMENTS
-
-
-#### IMPROVED SCHEMA SUPPORT
-There is now a "defaultSchemaName" parameter available for setting default schema. This schema will be used for all ambiguous database objects as well as for storing the databasechangelog and databasechangeloglock tables.
-
-#### NEW COMMANDS
-Ant support has been greatly expanded and now covers most of the functionality available in the command line application. See https://www.liquibase.org/documentation/ant/index.html for more information.
-
-#### NEW COMMANDS
-
-- changeLogSync
-- updateCount
-- updateCountSQL
-
-#### NEW REFACTORINGS
-
-- update change
-
-- delete change
-
-
-#### OTHER CHANGES
-
-
-- Custom Database implementations can be specified with the databaseClassName parameter
-- "replaceIfExists" attribute added to createView
-- createTable can specify uniqueConstraintName
-- Setting value/valueNumeric/valueBoolean/valueDate on addColumn will update all existing rows with the given value
-- Database table comments saved to generated change log
-- Changelog file comparisons are case-insensitive on windows
-- Output warning of old schema version
-- Added comments tag to generated SQL output
-- Rollback commands can specify contexts
-- XSDs are not pulled from network
-- Handles Postgres datatypes better
-- Bug fixes
-
-
-
-#### Upgrading
-
-Upgrading is simply a matter of replacing the liquibase.jar file. To take advantage of newer change log features, change your XSD declaration to:
-
-
-
-Depending on feedback received from this release, the 1.5.0.0 releases of the various plug-ins (Maven, Grails, IntelliJ, Eclipse) should be released over the next few days.
-
-As usual, be sure to let us know if you have any questions or issues.
-
diff --git a/_posts/2008-02-01-liquibase-core-151-grails-and-intellij-plugins-released.md b/_posts/2008-02-01-liquibase-core-151-grails-and-intellij-plugins-released.md
deleted file mode 100644
index 0682d6e69..000000000
--- a/_posts/2008-02-01-liquibase-core-151-grails-and-intellij-plugins-released.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Core 1.5.1 + Plugins
----
-
-# Liquibase 1.5.1 + Grails and IntelliJ Plugins Released
-Liquibase Core 1.5.1 has been released along with the initial 1.5.x series Grails and IntelliJ plugins.
-
-Changes to the core library are minor bug fixes including:
-
-- Fixed failOnError logic
-- Improved serial column detection in Postgres
-- Rollback connections before close for DB2
-- Other minor bug fixes
-
-The Liquibase core library can be downloaded, as usual, from https://download.liquibase.org/download-community/. The Grails and IntelliJ plugins are installed via their respective plugin managers
-
-The 1.5 Maven plugin should be released next week after further testing.
diff --git a/_posts/2008-02-04-why-arent-databases-version-controlled.md b/_posts/2008-02-04-why-arent-databases-version-controlled.md
deleted file mode 100644
index dee3f78d0..000000000
--- a/_posts/2008-02-04-why-arent-databases-version-controlled.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Why Aren't Databases Version Controlled?
----
-# Why aren't Databases Version Controlled?
-
-There was a great post the other day on Coding Horror titled
-["Get Your Database Under Version Control"](http://www.codinghorror.com/blog/archives/001050.html).
-It references a good [series of posts by K. Scott Allen](http://odetocode.com/Blogs/scott/archive/2008/01/30/11702.aspx)
-on database version control, but also makes the point that *"When it comes to version
-control, the database is often a second or even third-class citizen."*
-
-I have noticed this in the past as well, and have wondered why?
-
-## Lack of tools?
-
-Subversion, CVS, RCS and others have been around for years, but when I came the the
-realization that the database must be version controlled I could find no tools that
-fit my need and so created [Liquibase](https://www.liquibase.org/). I think
-lack of tools is a symptom of the problem rather than a cause, however. Developers
-have never been a group to sit around waiting for a tool to solve a pressing need they see.
-
-## DBA Overlords?
-
-In some organization changes to the database must go through a database change process
-managed by DBAs. The fact that the database changes are managed by an external group
-could create a "not our problem" situation where the developers depend on the DBAs to
-track changes. Again, I don't see this as a reason because the majority of projects
-do not have such a process in place and so wouldn't be depending on it.
-
-## Only Now a Big Problem?
-
-The answer that makes most sense to me is that database versioning is a relatively new
-problem. Code changes *need* to be propagated to every developer on a team quickly
-and reliably and therefore automated tools like Subversion and CVS have been around
-for a long time and no one would ever consider a group project without them. Most
-developers would not even consider a solo project without them.
-
-Databases, on the other hand, do not change as often and so manual and error-ridden
-processes have worked well enough in the past. As databases have become more and
-more central to projects of all types the old manual database update scripts are
-showing their limitations.
-
-I think the final straw in the ad-hoc database management schemes has come from the
-growth of agile processes. Pre-agile, even smaller projects would often design the
-database up-front and changes to it could be managed in a piecemeal fashion throughout
-the project. As agile does away with as much of the up-front design as possible, the
-number of database changes introduced throughout a project increases dramatically and
-a way to quickly, reliably, and automatically apply changes becomes a necessity.
-
-I see the existing database versioning tools like [Liquibase](https://www.liquibase.org/),
-[DBDeploy](http://www.dbdeploy.com/), and
-[ActiveRecord:Migration](http://api.rubyonrails.org/classes/ActiveRecord/Migration.html)
-as the [RCS](http://en.wikipedia.org/wiki/Revision_Control_System) of database
-versioning: they are a great start, but there is a lot of ground left to cover. Recent
-version of Liquibase have added features such as [database change rollback](/documentation/rollback.html),
-[database comparisons](/documentation/diff.html),
-[DBDoc](/documentation/dbdoc.html), and
-[change contexts](/documentation/contexts.html), but there is
-still a lot to do. That doesn't mean, however, that you shouldn't *Get your databse under version control*!
-
diff --git a/_posts/2008-02-07-liquibase-152-released.md b/_posts/2008-02-07-liquibase-152-released.md
deleted file mode 100644
index 265abc342..000000000
--- a/_posts/2008-02-07-liquibase-152-released.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.5.2 Released
----
-# Liquibase 1.5.2 Released
-
-Liquibase 1.5.2 has been released.
-
-Changes include:
-
-- Fixed bug with runOnChange and MD5sum check
-- Handles generating changelog for tables with composite primary keys
-- Other minor bug fixes
-
-The Liquibase core library can be downloaded via https://download.liquibase.org/download-community/.
-
-The Maven, Grails, and IntelliJ plug-ins have been updated and can be downloaded via their respective plug-in manager.
-
diff --git a/_posts/2008-03-27-liquibase-160-released-with-hiberate-support.md b/_posts/2008-03-27-liquibase-160-released-with-hiberate-support.md
deleted file mode 100644
index cb3fdf254..000000000
--- a/_posts/2008-03-27-liquibase-160-released-with-hiberate-support.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.6.0 Released with Hibernate Support
----
-# Liquibase 1.6.0 Released with Hibernate Support
-
-The Liquibase team is proud to announce the 1.6.0 Liquibase Core release.
-
-This release focuses primarily on Hibernate integration which allows you to use the
-[diffChangeLog](/documentation/diffChangeLog.html) functionality available with the
-command line and Ant to automatically generate Liquibase change sets based on new
-Hibernate mapping information.
-
-This functionality is similar to what is offered with hbm2ddl, but with the added ability
-to control and modify the changes before they are applied. For more information, see
-[https://github.com/liquibase/liquibase-hibernate](https://github.com/liquibase/liquibase-hibernate)
-
-Additional functionality includes a new [tagDatabase](/documentation/changes/tagDatabase.html) tag, a "primaryKeyName" attribute on the column tag, as well as many bug fixes.
-
-NOTE: Due to a bug in the change set md5 checksum generation in pre-1.6 releases, existing
-md5sum information needs to be cleared out of the databasechagelog table before running 1.6
-for the first time. This can be done by running
-[liquibase clearCheckSums](/documentation/command_line.html) or by running `UPDATE DATABASECHANGELOG SET MD5SUM=NULL`
-
-Upgrading is simply a matter of replacing the liquibase.jar file. To take advantage
-of newer change log features, change your XSD declaration to:
-
-
-
-
-Liquibase 1.6 can be downloaded from https://download.liquibase.org/download-community// and, as always, let us know if you have any questions or issues.
-
diff --git a/_posts/2008-04-23-liquibase-161-released.md b/_posts/2008-04-23-liquibase-161-released.md
deleted file mode 100644
index 01db02652..000000000
--- a/_posts/2008-04-23-liquibase-161-released.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.6.1 Released
----
-# Liquibase 1.6.1 Released
-
-Liquibase 1.6.1 has been released.
-
-This is primarily a bug fix release, but also includes a release of the 1.6 version to the Maven (still propagating), Grails, and IntelliJ repositories.
-
-Download Liquibase 1.6.1 from https://download.liquibase.org/download-community// and, as always, let us know if you have any questions or issues.
-
diff --git a/_posts/2008-06-25-liquibase-170-released.md b/_posts/2008-06-25-liquibase-170-released.md
deleted file mode 100644
index 46d612cf1..000000000
--- a/_posts/2008-06-25-liquibase-170-released.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.7.0 Released
----
-# Liquibase 1.7.0 Released
-
-It is Liquibase 1.0's first birthday, but you get the gift: Liquibase 1.7.0 is now available.
-
-Major changes include:
-
-- Added [loadData change](/documentation/changes/load_data.html) which allows importing of data from CSV files
-
-- Added support for [changelog parameters](/documentation/changelog_parameters.html) for more dynamic and flexible change logs
-- Allow [preconditions](/documentation/preconditions.html) in changeSet tags to act as sanity checks during a database update
-
-- Can export data with [generateChangeLog](/documentation/generating_changelogs.html)
-- Added markNextChangeSetRan command
-
-- Added validCheckSum tag to [changeSet](/documentation/changeset.html)
-
-- Can use any refactoring tags or reference previous changeSets inside a [rollback tag](/documentation/changeset.html#rollback_tag)
-
-- Allow [custom preconditions](/documentation/preconditions.html)
-- RowMapper interface is now public
-- Misc bug fixes
-
-The core library can be downloaded from https://download.liquibase.org/download-community// while the Maven, Grails, and IntelliJ plug-ins can be installed from their respective plug-in managers.
-
-
diff --git a/_posts/2008-07-10-martin-fowler-on-incremental-data-migration.md b/_posts/2008-07-10-martin-fowler-on-incremental-data-migration.md
deleted file mode 100644
index fc415e3bd..000000000
--- a/_posts/2008-07-10-martin-fowler-on-incremental-data-migration.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Martin Fowler on Incremental Data Migration
----
-# Martin Fowler on Incremental Data Migration
-
-Martin Fowler makes good points in his Incremental Migration Bliki post. Data migration is easy to push off or forget, and can often kill an otherwise great release--especially when valuable historical data gets lost due to a bad script.
-
-I think reason many people put off data migration scripts is because they mistakenly think that they are for release day only. In reality, however, data migration is needed throughout the development process including updating developer databases and migrating integration test data.
-
-Doing your data migrations incrementally and appending to your database change log on every refactoring will help you catch migration logic errors early and keep everyone's databases in sync.
-
-To keep up with your database migration scripts, you need to use the update your test/code/test cycle to:
-
-1. Write Test
-1. Run Test
-1. Code Change
-1. *Append database changes to change log*
-1. *Run Liquibase to update database*
-1. Run Test, See Green
-
-Making no database changes outside of your change log script and dev cycle will ensure that no changes get forgotten and that there are no differences between what happened on the developer's database and what happens on other developer's and production databases.
-
-To integrate Liquibase into your build process, there are Ant, and Maven front-ends available. This will allow you to migrate your integration tests data sets before executing them and allow you to find errors in your database update logic with each run.
diff --git a/_posts/2008-09-20-liquibase-180-released.md b/_posts/2008-09-20-liquibase-180-released.md
deleted file mode 100644
index cbf0c9f1a..000000000
--- a/_posts/2008-09-20-liquibase-180-released.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.8.0 Released
----
-# Liquibase 1.8.0 Released
-
-Liquibase 1.8.0 has been released and can be downloaded from https://download.liquibase.org/download-community//.
-
-Major changes include:
-## Improvements to [preconditions](/documentation/preconditions.html)
-
-- onFail and onError controls
-- Several new precondition checks
-- Custom preconditions can be passed parameters
-
-## SQLite Support
-
-- [Context](/documentation/contexts.html) checking is now case insensitive
-- Specifying a column as autoincrement for a non-autoincrement table does not cause an error
-- End delimiter can be specified with [sql changes](/documentation/changes/sql.html)
-- [Indexes](/documentation/changes/create_index.html) can be created as unique
-- Required attributes for all changes are checked before execution
-- [Command line migrator](/documentation/command_line.html) return codes are better
-- Many more bug fixes
-
-The Maven repository will be updated over the next couple days. The Grails and IntelliJ plug-ins are available immediately.
-
-I would also like to thank everyone who has helped with this release by submitting bug reports, feature requests, and patches. They are all greatly appreciated, so please keep them coming.
diff --git a/_posts/2008-10-01-liquibase-181-released.md b/_posts/2008-10-01-liquibase-181-released.md
deleted file mode 100644
index 8d7d256ac..000000000
--- a/_posts/2008-10-01-liquibase-181-released.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.8.1 Released
----
-# Liquibase 1.8.1 Released
-
-Liquibase 1.8.1 is now available for download. It is a bug fix release that fixes several minor bugs found in 1.8.0.
-
-As usual, if you have any questions or comments, please let us know.
\ No newline at end of file
diff --git a/_posts/2008-10-03-dealing-with-changing-changesets.md b/_posts/2008-10-03-dealing-with-changing-changesets.md
deleted file mode 100644
index 7d4e44ee6..000000000
--- a/_posts/2008-10-03-dealing-with-changing-changesets.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Dealing with Changing ChangeSets
----
-# Dealing with Changing ChangeSets
-
-The goal of a Liquibase change log file is to track the linear sequence of changes required to take a database from a starting point to the current state, and it is built up one change at a time throughtout development. By following the "always append changes" rule you will ensure that all databases are consistent since all will have gone through the exact same set of changes.
-
-If you go back and modify an old changeSet to incorporate a new change you will run into troubles because that change may have been ran against other databases and will not be ran again. To alert you to this problem, Liquibase stored checksums (md5 hashes) of each change that was ran. If the checksum of a changeSet in the current changelog file is different than what was executed before, Liquibase does not attempt to update anything.
-
-That being said, things never go according to plan, and so Liquibase has several options for dealing with changes to existing changeSets depending on your needs. Generally I see 3 main reasons for a change:
-
-## Original Change Set was Wrong or Buggy
-
-There are times when a change that was created wrong, especially if you are using the `` tag and have a complicated statement. When you catch the problem, you are often not able to recover original data or structures, but want the change to be correct for new databases going forward. In this case, it is best to use add a `` tag to the changeSet specifying that the new check sum is correct. To know the check sum to specify, simply make your change and try to update a database. The resulting verification error will include the new check sum.
-
-## Multiple change sets should be consolidated into a single change set
-
-There are times when several change sets should be consolidated into a single change for performance reasons. There has been talk on the mailing list about creating syntax support for this, but for now the best option is to simply remove the old change sets from the change log and create a new one. To keep the new change set from being run on databases that have already made the change the old way, use the `` precondition.
-
-### Example:
-
-
-
-
-
-
-
- ......
-
-
-
-## Change should never have been applied
-
-Perhaps you should never have moved data, or dropped a table. Whatevever the reason, there are times you want to reverse a done change set if it was executed and otherwise just skip it. The best way to handle this is similar to the combining change sets above. You simply delete the old changeSet from your changelog file and create a new changeset that will only run if the old changeset was ran.
-
-### Example:
-
-
-
-
-
- .....
-
-
-
-## More Options
-
-Beyond these options, there are several other tools available to use including the changeLogSync command, markNextChangeSetRan, preconditions based on the database state (``, `` etc.), or even manually editing the databasechangelog table to add or remove tables
-
diff --git a/_posts/2009-01-07-liquibase-190-released.md b/_posts/2009-01-07-liquibase-190-released.md
deleted file mode 100644
index 7b32e2c2a..000000000
--- a/_posts/2009-01-07-liquibase-190-released.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.9.0 Released
----
-# Liquibase 1.9.0 Released
-
-Liquibase 1.9.0 has been released!
-
-Major features include:
-
-- `modifySql` support
-- `includeAll` support
-- Sybase Adaptive SQL Anywhere support
-- Paths in `` can be relative to changelog using the "relativeToChangeLog" attribute
-- `stop` support
-- runInTransaction attribute for changeSet
-- Stronger validation in .xsd
-- Better Derby support (drop column, rename column)
-- Bug fixes
-
-
-If you are using the standard Liquibase library, upgrading is simply a matter of replacing the liquibase.jar file. If you are using Grails, Maven, or the IntelliJ plugin, an updated version should be available via standard plugin repository within in the next day.
-
-
-*NOTE: DUE TO A BUG IN THE "ADD NOT NULL CONSTRAINT" AND "DROP NOT NULL CONSTRAINT" CODE, YOU WILL GET CHECKSUM VALIDATION ERRORS FOR EXISTING CHANGESETS THAT USE THOSE TAGS. *
-
-
-To solve the problem, either:
-
-1. Add the `` tag to the failing changesets specifying the old MD5 sum (the one listed in the validation failed message)
-1. Or, run `UPDATE DATABASECHANGELOG SET MD5SUM=NULL`
-
-To take advantage of newer change log features, change your XSD declaration to:
-
-
-
-Download Liquibase 1.9 from: https://download.liquibase.org/download-community/
-
-
-As usual, make sure you let us know if you have any questions, problems, or ideas. Also, thank you to everyone who submitted bug reports and patches over the last couple months.
diff --git a/_posts/2009-01-12-a-note-on-version-numbering.md b/_posts/2009-01-12-a-note-on-version-numbering.md
deleted file mode 100644
index fefee676f..000000000
--- a/_posts/2009-01-12-a-note-on-version-numbering.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: A Note on Version Numbering
----
-# Note on Version Numbering
-
-There are times when I have seen projects with a version 1.9 that means "the last 1.x release before 2.0". In our case, "1.9" simply means "the release after 1.8"
-
-
-After a bit of discussion on the liquibase-user mailing list, we decided that we didn't want to go to a 2.0 release at this point because there has not been any major changes and we have kept backwords compatibility.
-
-
-Therefore, we are going to continue our current 1.x numbering strategy and continue to provide evolutionary improvements for the foreseeable future. 1.10, 1.11 etc. do look a bit confusing and like 1.1.0, 1.1.1 etc, but I think most Liquibase users will be smart enough to figure it out :)
diff --git a/_posts/2009-02-20-liquibase-191-released.md b/_posts/2009-02-20-liquibase-191-released.md
deleted file mode 100644
index 5fae75902..000000000
--- a/_posts/2009-02-20-liquibase-191-released.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.9.1 Released
----
-# Liquibase 1.9.1 Released
-
-Liquibase 1.9.1 has been released which addresses several bugs. Most bugs were relatively minor, but it is recommended you upgrade.
-
-Some of the bugs fixed include:
-
-- H2 schema capitalization issues
-- Improved "local database" detection
-- Improved database snapshot generation for Oracle and MSSQL
-- Bug fixes in Sybase AS Anywhere support
-- Handle urls with an authority component when using includeAll
-- Fixed bug with "runInTransaction" attribute
-- Support for Grails 1.1-SNAPSHOT
-- Escape hsql tables/columns that are keywords
-
-
-As usual, visit https://download.liquibase.org/download-community/ to download the update.
-
diff --git a/_posts/2009-03-24-what-effects-changeset-checksums.md b/_posts/2009-03-24-what-effects-changeset-checksums.md
deleted file mode 100644
index 01f02c311..000000000
--- a/_posts/2009-03-24-what-effects-changeset-checksums.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: What Effects ChangeSet Checksums?
----
-# What Effects ChangeSet Checksums?
-
-We store an md5 checksum with each changeset entry in the database changelog table to detect differences between what is currently in the changelog and what was actually ran against the database.
-
-
-We try to keep as many false-positives and false-negitives out of the process by taking only the database change related tags,normalizing the XML, and then creating the checksum.
-
-
-That means that you can reformat your XML (for the most part) as well as add or change preconditions, contexts, and validCheckSum tags without effecting the checksum. The only time that the xml reformat can cause problems is if a text block such as an `` tag is reformatted.
-
-
-So don't fear the checksum. It is there to help you out and you can add information around already ran changesets without problems. And if you do need to change your original changes, there are ways to deal with the checksum problems.
diff --git a/_posts/2009-04-06-liquibase-192-released.md b/_posts/2009-04-06-liquibase-192-released.md
deleted file mode 100644
index f7657c6a9..000000000
--- a/_posts/2009-04-06-liquibase-192-released.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.9.2 Released
----
-# Liquibase 1.9.2 Released
-
-Liquibase 1.9.2 has been released. It is a bugfix release, mainly around issues with the includeAll tag.
-
-
-Like always, it can be downloaded from https://download.liquibase.org/download-community/
diff --git a/_posts/2009-04-17-moving-test-datasets-across-database-types.md b/_posts/2009-04-17-moving-test-datasets-across-database-types.md
deleted file mode 100644
index 625fa4a0b..000000000
--- a/_posts/2009-04-17-moving-test-datasets-across-database-types.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Moving Test Datasets Across Database Types
----
-# Moving Test Datasets Across Database Types
-
-While the main goal of Liquibase is database change tracking, I found a very different use for it lately: moving test datasets.
-
-I have an application that has been traditionally developed on MySQL, but am in the process adding MS SQL support as well. The application uses Hibernate so it *should* work in theory, but does it *really* work on SqlServer?
-
-Since I have unit tests already set up that actually execute the data access layer against the database, I can run them against MS SQL instead, but the tests require data (and often specific data).
-
-I wasn't looking forward to duplicating my test data management effort, and so I started looking for a way to move the data from MySQL to SqlServer. I tried mysqldump (even with the "mssql compatability mode") but it was still too MySQL specific. There are MS SQL migration tools, but I wanted it to be automated and be flexible enough to move the app to Oracle, DB2, etc. in the future. In particular, I was also wondering if running the DAO tests against H2 would be faster, but that is another blog post...
-
-What I ended up doing was using Liquibase's generateChangeLog functionality to output the database schema and data. The steps I run are:
-
-1. Call generateChangeLog telling liquibase to export data as well. I used the Liquibase API to integrate it into my script easier.
-1. Load the changelog into a DOM and update any mysql specific or SqlServer unsupported functionality using xpath. For example, convert BIGINT(20) to BIGINT.
-1. Run the changeLog against the target database. This may take a bit of trial and error to find all your particular database incompatabilities.
-1. Delete all rows from the target database's databasechangelog table
-1. Select all rows from the base database's databasechangelog table and insert the values into the new database's databasechangelog table. This will make sure that the database history liquibase sees in future attempts at updating is correct.
-
-Now, I can continue to manage my dataset in MySQL like I always have but still magically have my test database and dataset available for testing against using MS SQL.
-
-
-While I would not recommend using this for a production backup/restore scenario (the Liquibase diff tool does not export everything), it has been working great for managing and migrating the test dataset.
diff --git a/_posts/2009-04-22-extensibility-roadmap-for-110.md b/_posts/2009-04-22-extensibility-roadmap-for-110.md
deleted file mode 100644
index cda6788ab..000000000
--- a/_posts/2009-04-22-extensibility-roadmap-for-110.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Extensibility Roadmap for 1.10
----
-# Extensibility Roadmp for 1.10
-
-My plan for 1.10 is to focus on extensibility. I wanted to make sure I have good goals for that in mind, and that what we are planning to do will match up with those goals.
-*2. Create 3rd party community.*
-
-a. Ability to override what SQL is sent to the database for standard databases and refactorings (Add engine innodb to all create table statements, LoadData on MSSQL should call "set identity insert on/off", etc)
-
-b. Ability to add custom Change classes and use them from the changeset
-
-c. Ability to create a custom changelog parser as an alternative to the standard XML
-
-d. Better documentation of how the liquibase API can be used within an application
-
-e. Ensure that all liquibase APIs will remain stable for the foreseeable future
-
-*2. Create 3rd party community.* There are many refactorings that we do not want to support in the core because they are database specific or limited in scope (vacuum database, set identity_insert on, etc).
-
-a. Create a "contrib" area on the site that people can upload useful extensions that are not in the core
-
-b. Developer documentation on extending liquibase
-
-c. Better issue/feature tracker that supports extensions?
-
-d. Better mailing list/newsgroup setup
-
-e. Ensure that all documented extension points will remain stable for the foreseeable future
-
-*3. Make core codebase more approachable to submissions:*
-
-a. Better developer documentation
-
-b. Document migration path from 3rd party extension to core functionality
-
-c. Refactoring of codebase to make it easier to add new Database, Change, and Statement classes without touching as much other code
-
-d. Better unit test coverage to stop regression errors
-
-
-
-Is there any particular use cases related to extensibility you want to make sure are addressed? What am I missing?
-
-
-I plan to follow up with requests for in-depth comments on each of these steps as we get to them and can say exactly what we are implementing.
diff --git a/_posts/2009-04-22-looking-for-feedback-on-statement-refactoring.md b/_posts/2009-04-22-looking-for-feedback-on-statement-refactoring.md
deleted file mode 100644
index 7a643c51e..000000000
--- a/_posts/2009-04-22-looking-for-feedback-on-statement-refactoring.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Feedback on Statement Refactoring
----
-# Looking for Feedback on Statement Refactoring
-
-I am starting the extensibility refactoring at the \*Statement class level and moving up from there. I committed an initial version of what I am thinking to trunk, and am looking for feedback (either in comments, or directly to me at nathan@voxland.net).
-
-### Renamed liquibase.database.sql package to liquibase.database.statement.
-
-We may want to support non-"sql" statements in the future, so the name change seemeded best
-
-### Separated out the creation of SQL from the \*Statement class.
-
-Before each Statement class had a "String getSqlStatement(Database)" method that would create a string containing the database specific sql required to run the statement. Now, there is a liquibase.database.statement.generator package that contains classes that take a Statement instance containing the information about a statement (table name, column names, etc) and converts them into SQL strings.
-
-There is now a SqlGeneratorFactory singleton with a "SqlGenerator getBestGenerator(SqlStatement statement, Database database)" method. When we get to the point where we have Statement classes that need to be executed, liquibase will call this method to get the correct SqlGenerator instance for a given statement and database and use that instance to create the sql to execute. (this change has not been made yet) .
-
-The SqlGeneratorFactory has a list of all SqlGenerators available. That list is built up via a reflection package search in the liquibase.database.statement.generator package and sub-packages, or via a SqlGeneratorFactory.register() method. There will be a standard package of liquibase.database.statement.generator.ext that can be used by 3rd parties to have their statements registered automatically without using the register ethod.
-
-I have started breaking up the Statement classes (although I haven't removed the old getSqlStatement methods yet). In the liquibase.database.statement.generator package there is an SqlGenerator interface which provides a getSpecializationLevel method, an isValid method, and a generateSql method. In the getBestGenerator() method, the SqlGeneratorFactory will loop through all known generators and call the isValid method to determine if a given SqlGenerator would work for that combination of database and statement. Once it has a list of good generators, it will call the getSpecialiazationLevel() method which returns an int corresponding to how "good" that generator is for that statement/database combo. There should usually be a default generator for each statement that will have a level of 1. There will often be database-specific versions of the generator that return a level of 5. 3rd party Statement generators can return any level they want to override the built in ones or other 3rd party generators. If no generators are found for a database/statement combo, tyere is a NotImplementedGenerator that is returned that simply throws an exception.
-
-### New generateSql method returns an array.
-
-Before, there was a one-to-one correspondence between a Statement class, and the SQL generated. I think there are situations, however, where a Statement may generate multiple SQL commands and so we should allow the return of an array.
-
-### generateSql returns instances of "Sql", not Strings
-
-This is the part I go back and forth on. Since the goal of this refactoring is to give 3rd party developers an API to code against, I want to do my best to make sure that API is not going to change. There has been talk in the past about building more flexibility into the system by giving back an syntax tree that can be modified before being executed. The idea with the Sql interface, is that we would only have an "UnparsedSql" implementation at first, but may make smarter implementations in the future.
-
-The question is: is this too much? We now have a mechanism where we can override what sql string is generated for a particular database and/or statement, is that going to cover all the low-level-sql-tweaking that we would need? I feel like the Sql interface may allow some sort of cross-cutting sql modification, or similar, but it is just a half-thought out idea.
-
-### Improving tests
-
-I am going to repurpose the test framework around the Statement classes that actually run them against the database. This has not been done yet.
-
diff --git a/_posts/2009-04-30-community-infrastructure-improvements-part-i.md b/_posts/2009-04-30-community-infrastructure-improvements-part-i.md
deleted file mode 100644
index fdc785db2..000000000
--- a/_posts/2009-04-30-community-infrastructure-improvements-part-i.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Community Infrastructure Improvements, Part I
----
-# Community Infrastructure Improvements Part 1
-
-Thanks to the generous people at Atlassian, we now have a much nicer issue tracker and source browser than before. You can check out our Jira instance at http://liquibase.jira.com/browse/CORE.
-
-
-The issues were bulk moved from the sourceforge tracker, so I will be going over them to recategorize and prioritize them over the next week.
-
-
-We also now have a message board at https://forum.liquibase.org/ in place of the old liquibase-user, liquibase-devel, and liquibase-doc mailing lists. A copy of all top-level (non-reply) posts are being forwarded to the mailing lists to help with the transition, but please use the forum from now on.
-
-
-If you have any comments or suggestions on the new setup, please let me know.
diff --git a/_posts/2009-04-30-twitter-of-the-day.md b/_posts/2009-04-30-twitter-of-the-day.md
deleted file mode 100644
index 56f144996..000000000
--- a/_posts/2009-04-30-twitter-of-the-day.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Twitter of the Day
----
-# Twitter of the Day
-
-> @leopinheiro: I want to use Liquibase with Rails (like a plugin), any idea?
-
-When I started Liquibase, I quickly threw out the idea of creating a Java port of Rail's Migrations. Over the years, a common question is "why doesn't this work like Migrations?" It is nice to see at least one person in the Rails community that sees the light :)
-
diff --git a/_posts/2009-05-13-liquibase-as-a-job-requirement.md b/_posts/2009-05-13-liquibase-as-a-job-requirement.md
deleted file mode 100644
index c526eeb0f..000000000
--- a/_posts/2009-05-13-liquibase-as-a-job-requirement.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase as a Job Requirement
----
-
-# Liquibase as a Job Requirement
-
-Saw Liquibase as a requirement on dice.com today.
-
-
-It's nice to see that it is becoming important enough to companies for them to list it as an important skill.
-
-
-Either that or it is so difficult to use that companies do not think it is something that they can train new hires on in a reasonable amount of time....
diff --git a/_posts/2009-05-19-liquibase-20-status.md b/_posts/2009-05-19-liquibase-20-status.md
deleted file mode 100644
index 98298ddfd..000000000
--- a/_posts/2009-05-19-liquibase-20-status.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 Status
----
-# Liquibase 2.0 Status
-
-I have been working hard on Liquibase 2.0 lately, and it feels very, very good to be updating and cleaning up the codebase. I am putting the SOLID principals to work, increasing test coverage, and building in integration hooks.
-
-
-So you do not worry, The changelog XML format will stay the same and be completely backwards compatible with the 1.x series so the vast majority of users will see little to no changes. It is only the underlying java classes that will change significantly. If you are using any liquibase classes directly, this will be a large change for you, but the number of people using the API is small enough that it is worth simplifying and standardizing now, before really opening up the library for extension like the plan is. We will provide a migration guide for anyone needing it.
-
-
-Curently I feel I am about 1/2 done with the main code update, which means that in about 1 month we should have a beta 1 release. The plan is to have a series of beta releases before the final release.
-
-
-With beta 1, I am hoping to open up a plug-in contest. There will be many new integration points around modifying what SQL gets ran for a change, new database support, new changes, new changelog parsers, and more. There are many tools and enhancements that would be very helpful to some, but not general purpose enough to make it into the core application that would make great plugins, so get thinking. Despite having no budget, I would like to kick off the extensibility support with a bang, hopefully I can find a company willing to throw in a prize for some PR. Wost case, the grand prize will be a copy of mysql community server and sqlserver desktop edition :)
-
-
-Despite not being finished with the refactoring, feel free to review the code and give me any feedback (or patches) you have. There are many use cases i have heard over the years that I plan on supporting, but there the best ones are often the ones I never thought of.
diff --git a/_posts/2009-06-04-3rd-party-liquibase-training.md b/_posts/2009-06-04-3rd-party-liquibase-training.md
deleted file mode 100644
index 1894167c1..000000000
--- a/_posts/2009-06-04-3rd-party-liquibase-training.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: 3rd Party Liquibase Training
----
-# 3rd Party Liquibase Training
-
-On the Agile Database group the other day, there was a message that mentioned that their company provided a training course that included Liquibase.
-
-
-*Note:* I know nothing about the course beyond the link above, but I know there has been interest in Liquibase training in the past and this may be a useful option for some.
-
-
-I am mentioning it because it is the first professional Liquibase training I have seen, and also because of their quote on the group: "Run, don't walk to liquibase.org and find out more about this lifesaver."
diff --git a/_posts/2009-06-04-database-version-control-on-stackoverflow-podcast.md b/_posts/2009-06-04-database-version-control-on-stackoverflow-podcast.md
deleted file mode 100644
index d1f49d7b2..000000000
--- a/_posts/2009-06-04-database-version-control-on-stackoverflow-podcast.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Database Version Control on StackOverFlow Podcast
----
-# Database Version Control on StackOverflow Podcast
-
-One of the questions that was discussed on a recent StackOverFlow podcast was "Do you source control your database".
-
-
-It is, obviously, a question near to my heart and I very much agree with the answer of "YES". I also like that "use liquibase" has a few up votes and isn't too far down the page...
-
-
-It is great to see the concept getting some attention. I know that managing your database changes is just as vital as managing your code changes, yet the discussion, tool support, and interest is significantly higher for code version control than it is for database version control. There are endless articles and podcasts on SVN vs. Git, source control best practices, and mocking of people still using CVS and VSS, but basically no mention of Liquibase vs. ActiveMigrations, database changeset best practices, or mocking of people manually managing their database changes or using database diff tools.
-
-
-I know Liquibase has saved my butt as many times as SVN has, and I want it to be able to help as many other developers as possible. The first step, however, is learning that there are tools out there that will help them.
diff --git a/_posts/2009-06-05-liquibase-online-meetup-thurs-june-25-2009-1200-pm-us-central-time.md b/_posts/2009-06-05-liquibase-online-meetup-thurs-june-25-2009-1200-pm-us-central-time.md
deleted file mode 100644
index bcb8833e5..000000000
--- a/_posts/2009-06-05-liquibase-online-meetup-thurs-june-25-2009-1200-pm-us-central-time.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Online Meetup
----
-# Liquibase Online Meetup
-
-We will be having our first meetup 2009-6-25 at 12:00 PM US central time (GMT-5) using the "Chat" functionality of the Liquibase community forum (https://forum.liquibase.org/). To log in, you will need to be registered.
-
-
-I will be there to discuss the upcoming 2.0 release, development processes, outstanding issues and feature requests, and anything else of interest to participants. Planned time is 1 hour.
-
-
-Hope to see you there.
diff --git a/_posts/2009-06-23-liquibase-194-released.md b/_posts/2009-06-23-liquibase-194-released.md
deleted file mode 100644
index 349ba12f0..000000000
--- a/_posts/2009-06-23-liquibase-194-released.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.9.4 Released
----
-# Liquibase 1.9.4 Released
-
-Liquibase 1.9.4 has been released. The 1.9.x branch continue to be maintained, even as work continues on Liquibase 2.0.
-
-
-1.9.4 is primarily a bug fix release, but also introduces the following features:
-
-
-- DB2 for iSeries support
-- Improved Maven support
-- executeCommand does not run under updateSQL etc.
-
-
-
-As usual, you can download the newest version from https://download.liquibase.org/download-community/ and post any questions or issues to https://forum.liquibase.org/
-
-
-
-We would like to thank Mark Logemann, Don Smith, and Oleg Taranenko for the patches they submitted.
diff --git a/_posts/2009-06-24-liquibase-20-milestone-1-released.md b/_posts/2009-06-24-liquibase-20-milestone-1-released.md
deleted file mode 100644
index 536c23631..000000000
--- a/_posts/2009-06-24-liquibase-20-milestone-1-released.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 Milestone 1 Released
----
-# Liquibase 2.0 Milestone 1 Released
-
-The first public release of Liquibase 2.0 is now available. *This release is a milestone release, and therefore not for general consumption, it is not even at beta stage yet. *
-
-
-The focus of milestone 1 was a major refactoring and standardization of the external-facing APIs to give 3rd party extension contributors a stable platform to build on. We have not yet begun to address bugs found in 1.9 or implement new functionality. Additionally, the checkum generation logic has changed and is currently incompatible with checksums generated in liqubase 1.x. Liquibase 2.0 final will handle upgrades graceful.
-
-
-Because it is just a milestone release, the download packages are not on sourceforge, but are linked from the download page.
-
-
-Please let us know of any feedback, questions, or bugs you find. Although we have focused on stabilizing the API, parts may change during the milestone phase based on feedback from the community.
-
-
-The roadmap for 2.0 is to have several milestone releases, followed by a beta period. 2.0 final is scheduled for a September release, although that may change.
-
-
-*Note: Don't forget the Liquibase online meetup tomorrow!*
diff --git a/_posts/2009-06-24-liquibase-extension-contest-2009-now-underway.md b/_posts/2009-06-24-liquibase-extension-contest-2009-now-underway.md
deleted file mode 100644
index 58c4e6416..000000000
--- a/_posts/2009-06-24-liquibase-extension-contest-2009-now-underway.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Extension Contest 2009
----
-# Liquibase Extension Contest 2009 Now Underway
-
-Liquibase 2.0 is all about 3rd party extension and integration, and to help kick that off, we are holding a contest.
-
-
-Thanks to donations from Atlassian and O'Reilly, we have some great prizes for the winners
-
-
-### Rules
-
-
-- Your entry must embed or extend Liquibase
-- Extensions must be compatible with Liquibase 2.0 (currently under construction)
-- Your plugin must be listed on the Liquibase Extension Portal
-- You must announce your extension and your interest in submitting it to this contest on the Liquibase User Forum
-- There is no license restrictions on your plugin, although we prefer an open source license
-
-
-### Prizes
-
-Grand Prize:
-
-- Your choice of 5 O'Reilly books, donated by O'Reilly
-- One copy of PostgreSQL
-
-
-
-Runner Up:
-
-
-
-- Atlassian laptop bag from Timbuk2 (US$150 value), donated by Atlassian
-- One copy of MySQL Community Edition
-
-
-
-5x Honorable Mentions:
-
-
-
-- Your choice of 1 O'Reilly book, donated by O'Reilly
-- One copy of JavaDB
-
-
-
-### Judging
-
-
-
-The winning plugins will be judged by lead developer Nathan Voxland on:
-
-
-- Usefulness
-- Creativity and Elegance
-- Completeness
-- Code quality and documentation
-
-
-
-### Key Dates
-
-
-
-- June 24th, 2009: Contest opens
-- August 31st, 2009, High Noon, US Central Time (GMT-5): Contest closes
-- September 15th, 2009: Winners Announced
-
-
-
-For more information, see the offical contest page
-
diff --git a/_posts/2009-06-24-now-open-liquibase-extension-portal.md b/_posts/2009-06-24-now-open-liquibase-extension-portal.md
deleted file mode 100644
index 705fa01c3..000000000
--- a/_posts/2009-06-24-now-open-liquibase-extension-portal.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Now Open Liquibase Extension Portal
----
-# Now Open: Liquibase Extension Portal
-
-Although it is currently just a skeleton of what it will be, the Liquibase Extension Portal is now open at https://www.liquibase.org/extensions.
-
-
-The goal of the extension portal is to provide:
-
-
-- A place for database-specific or experimental functionality that has not/should not be incorporated into the main Liquibase library
-- A single location for end-users to find plug-ins of value to them
-- An easy way for 3rd parties to submit, manage and maintain plug-ins by providing a documentation wiki, issue tracking, and source control
-- Documentation on how to create your own extensions for public or private use
-
-
-
-I was hoping to improve the sample extension pages (set-identity-insert and vacuum) to provide a better template, but I wanted to get something out before the online meetup tomorrow. We will improve the content on the portal over the next week once real work settles down.
-
-
-
-As always, let us know if you have any questions or comments on the portal.
diff --git a/_posts/2009-07-06-liquibase-20-beta-1-released.md b/_posts/2009-07-06-liquibase-20-beta-1-released.md
deleted file mode 100644
index 2f0e5e644..000000000
--- a/_posts/2009-07-06-liquibase-20-beta-1-released.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 Beta 1 Released
----
-# Liquibase 2.0 Beta 1 Released
-
-Beta 1 of Liquibase 2.0 has been released. It can be downloaded from https://download.liquibase.org/download-community/.
-
-
-The main improvement over milestone 1 is that it can be ran against existing changelog scripts, so it can be fully tested with existing databases.
-
-
-Also, do not forget the Liquibase Extension Contest currently underway!
diff --git a/_posts/2009-07-15-extension-ideas.md b/_posts/2009-07-15-extension-ideas.md
deleted file mode 100644
index 57c4f8f74..000000000
--- a/_posts/2009-07-15-extension-ideas.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Extension Ideas
----
-# Extension Ideas
-
-The Liquibase plugin contest is underway and there is still time to submit your extensions. If you are looking for inspriation, there is now an "Ideas Page" on the Extension Portal to get you started.
-
-
-If you are not planning on creating an extension, but have something that you would like to see created, please add it to the list as well.
-
-
-Remember, the contest deadline is August 31st and the sooner you submit an entry, the more time you have for feedback to improve it before the contest ends.
diff --git a/_posts/2009-07-17-net-liquibase-port-any-volunteers.md b/_posts/2009-07-17-net-liquibase-port-any-volunteers.md
deleted file mode 100644
index ccd559d19..000000000
--- a/_posts/2009-07-17-net-liquibase-port-any-volunteers.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: .Net Liquibase Port Volunteers
----
-# .Net Liquibase Port: Any Volunteers?
-
-As part of re-evaluating the Liquibase APIs as part of the 2.0 codebase, I started an experimental .Net implementation to see what changes would need to be incorporated into the regular codebase to produce a liquibase.dll with as new little code as possible. I have the code to the point that I know it would work, and can see the direction it would need to go, but I will not have time to fully implement it for quite some time. That is where you could come in...
-
-
-Despite thinking about alternate languages, I ended up finding that ikvm is the best option for us. I was able to split the existing java code into a "core" and "core-jvm" source directories. The "core" code is/will be java code, but without any jdbc or xml libraries (or java-specific technologies like Ant, Maven, and Servlets). The core-jvm source is all the remaining "java specific" code.
-
-
-I then compiled the "core" java library into a dll and added it as a reference in a new "core-clr" source directory and visual studio solution. I was able to begin implementing the liquibase abstraction interfaces using OleDbConnection-based classes.
-
-
-What is the current state? The liquibase code is divided between core, core-jvm, and core-clr, but the core-clr is far from complete. Since we can use the core liquibase.dll, 90% of the liquibase code will be shared between the two projects, so bugfixes will be applicable to both, new features will be applicable to both, and the .net port will include all the cross-database support and refactorings that currently exist in liquibase. What needs to be done is:
-
-
-- Re-implement the connection based logic using OleDbConnection (or better .net interface?). This includes translating the abstracted liquibase "execute this sql" calls as well as the database metadata reading logic.
-- Re-implement the XML parser using .net libraries. This has not been started, but the abstractions are already there in the liquibase code.
-- Create any .Net specific integrations (IIS, NHibernate, MSBuild, Installer, etc.)
-
-
-
-If you are interested in helping, please send me an email (nathan@voxland.net). You do not need to be proficient in java to help, we can handle any changes to the java liquibase codebase to support you as needed.
-
diff --git a/_posts/2009-07-21-liquibase-20-beta-2.md b/_posts/2009-07-21-liquibase-20-beta-2.md
deleted file mode 100644
index 19fef8d04..000000000
--- a/_posts/2009-07-21-liquibase-20-beta-2.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 Beta 2
----
-# Liquibase 2.0 Beta 2
-
-Liquibase 2.0 beta 2 is now available. You can download it from https://download.liquibase.org/download-community/.
-
-
-There is no new major functionality yet, but lots of reorganized code and a plugin-framework that works with the command line.
-
-
-Let us know if you have any issues with it.
diff --git a/_posts/2009-08-05-liquibase-online-meetup-wed-august-19th-1200-pm-gmt-5.md b/_posts/2009-08-05-liquibase-online-meetup-wed-august-19th-1200-pm-gmt-5.md
deleted file mode 100644
index a931334a8..000000000
--- a/_posts/2009-08-05-liquibase-online-meetup-wed-august-19th-1200-pm-gmt-5.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Online Meetup 2009
----
-# Liquibase Online Meetup 2009
-
-We will be having an online meetup Wednesday August 19th, 2009 at 12:00 PM US central time (GMT-5) using the "Chat" functionality of the Liquibase community forum (http://liquibase.org/forum/chat/index.php). To log in, you will need to be registered on http://www.liquibase.org/forum/
-
-
-I will be there to discuss the upcoming 2.0 release, development processes, outstanding issues and feature requests, and anything else of interest to participants. Planned time is 1 hour.
-
-
-Hope to see you there.
diff --git a/_posts/2009-08-31-extension-contest-extended.md b/_posts/2009-08-31-extension-contest-extended.md
deleted file mode 100644
index fb4485a72..000000000
--- a/_posts/2009-08-31-extension-contest-extended.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Extension contest extended
----
-
-# Extension Contest Extended
-
-Due to us missing milestones on the liquibase 2.0 release, we are pushing the deadline for the plugin contest back to noon Central US time, September 30th. Winners announced October 15th All other rules are the same.
-
-
-Full details
diff --git a/_posts/2009-09-17-liquibase-195-released.md b/_posts/2009-09-17-liquibase-195-released.md
deleted file mode 100644
index b3d4f658b..000000000
--- a/_posts/2009-09-17-liquibase-195-released.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 1.9.5 Released
----
-# Liquibase 1.9.5 Released
-
-Liquibase 1.9.5 has been released, and can be downloaded from Liquibase download page
-
-
-This is purely a bugfix release. As usual, let us know on the forums if you have any troubles.
diff --git a/_posts/2009-09-17-liquibase-20-beta-3-released.md b/_posts/2009-09-17-liquibase-20-beta-3-released.md
deleted file mode 100644
index 090222249..000000000
--- a/_posts/2009-09-17-liquibase-20-beta-3-released.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 Beta 3 Released
----
-
-# Liquibase 2.0 Beta 3 Released
-
-Liquibase 2.0 Beta 3 has been released. *Note: This is not yet production ready code and contains known issues*
-
-
-The goal of the beta3 release is to provide a new stable release for entries in the plugin contest to build off of and for others who want to beta test the 2.0 release.
-
-
-Major changes in the beta3 release include:
-
-
-- Converting to Maven for our build process
-- Major changes to the database snapshot functionality including better flexibility and performance
-- Lots of bug fixes
-
-
-
-Beta 3 should be the last "re-architecting" release. From now until the 2.0 final release we are going to focus on new features and bug fixes. The goal for 2.0 final is mid-September.
-
-
-
-As always, let us know if you have any questions or problems.
-
-
-You can download the newest release from the Liquibase download page
diff --git a/_posts/2009-09-20-continuous-build-server-now-availalbe.md b/_posts/2009-09-20-continuous-build-server-now-availalbe.md
deleted file mode 100644
index 98b094b47..000000000
--- a/_posts/2009-09-20-continuous-build-server-now-availalbe.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Continuous Build Server Now Availalbe
----
-# Continuous Build Server Now Available
-
-Thanks to the people at ops4j.org loaning us some space on their build server, we now have a build server available. It will (and has) helped ensure we keep our tests clean, and provides a place where anyone can download the latest build of liquibase.
-
-
-We would like to thank Damian Golda in particular for helping getting us set up with the ops4j people.
diff --git a/_posts/2009-09-25-liquibase-2-0-beta-4-released.md b/_posts/2009-09-25-liquibase-2-0-beta-4-released.md
deleted file mode 100644
index 2cabb084d..000000000
--- a/_posts/2009-09-25-liquibase-2-0-beta-4-released.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 Beta 4 Released
----
-# Liquibase 2.0 Beta 4 Released
-
-Beta 4 of Liquibase 2.0 is now available from Liquibase download page
-
-
-The major improvement over beta 3 is the fact that it will actually run...
-
-
-Other improvements include:
-
-
-- Improved Oracle type mappings
-- "context" attribute is available on modifySql
-- Improved computed value detection and handling, including new "valueComputed" and "defaultValueComputed" attributes on
-
-`` and ``
-
-- More bug fixes
-
-
-
-If you have any issues or questions, please let us know
-
diff --git a/_posts/2009-10-08-liquibase-2-0-rc1-released.md b/_posts/2009-10-08-liquibase-2-0-rc1-released.md
deleted file mode 100644
index d9b1cabdb..000000000
--- a/_posts/2009-10-08-liquibase-2-0-rc1-released.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 RC1 Released
----
-# Liquibase 2.0 RC1 Released
-
-Liquibase 2.0 Release Candidate 1 is now available from the Liquibase download page
-
-
-The primary focus of the 2.0 release is extensibility and building community. In particular, this means infrastructure changes such as:
-
-
-- Major re-architecting of codebase to expose a flexible, extensible, stable API
-- Replacing the old mailing lists with a message system
-- Extension/plug-in portal and Extension Contest (closed for judging)
-- New Feature/Issue tracker
-- New source repository and browser
-- Publicly available build server
-- Scheduled online meetups
-- Maven as build script
-- Improved documentation including developer documentation (still to do)
-- Improved test coverage
-
-### As well as new functionality including:
-
-- Ability to specify databases and contexts in which to specify changelog parameters
-- Ability to specify contexts on modifySql
-- ChangeLogPropertyDefined precondition
-- Performance improvements
-- Lots of bug fixes
-
-
-### Current state of Liquibase 2.0:
-
-As of the RC1 release, all scheduled features are implemented and our unit and integration tests have passed. For the next few weeks as we work through the RC cycle, I will be updating documentation and fixing reported bugs.
-
-
-### Upgrade Nodes:
-
-- The format of the changeset checksums stored in the databasechangelog table has changed. All checksums will automatically be upgraded to the new format, but will not be backwards compatible with 1.x. We cannot determine changed changesets so any invalid checksums or runOnChange features are disabled for the first 2.0 run
-- The modifyColumn tag has been deprecated and moved to the extension portal. If you are using modifyColumn, consider the new `` or other more specific comands (addPrimaryKeyConstraint, etc.) and/or include the modifyColumn library in your classpath.
-- The format of the XSD definition has changed.
-
-The new format looks like:
-
-
-
-Please give Liquibase 2.0 a try and report any issues or questions you have.
-
diff --git a/_posts/2009-10-15-liquibase-2009-plugin-contest-winners.md b/_posts/2009-10-15-liquibase-2009-plugin-contest-winners.md
deleted file mode 100644
index f2e98ae05..000000000
--- a/_posts/2009-10-15-liquibase-2009-plugin-contest-winners.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2009 Plugin Contest Winners
----
-# Liquibase 2009 Plugin Content Winners
-
-Congratulations to the winners of the 2009 Liquibase Plugin Contest!
-
-
-*Grand Prize (Choice of 5 O'Reilly Books, donated by O'Reilly):*
-
-
-Oracle Extensions by Artur Kopacz, Damian Pezda, Lukasz Rejkowicz, Tomasz Wicherski
-
-
-*Runner Up (Laptop Bag, donated by Atlassian):*
-
-
-Liquibase for JRuby on Rails by Tal Rotbart
-
-
-#### Honorable Mentions (Choice of one O'Reilly Book):
-
-1. GarinDriver by Mark Farnsworth
-1. TableCount Precondition by Chris Imershein
-1. PostgreSQL Extensions by Shane Miller
-1. MS SQL Server Extensions by Dave Gorman
-1. Liquibase Documentation, Japanese Translation by Yasuo Honda
-
-I would like to thank everyone who participated, as well as the generous prize donations by Atlassian and O'Reilly. I will be contacting the winners via email, if you do not hear from me, please let me know.
diff --git a/_posts/2010-05-12-liquibase-formatted-sql.md b/_posts/2010-05-12-liquibase-formatted-sql.md
deleted file mode 100644
index 809c3092c..000000000
--- a/_posts/2010-05-12-liquibase-formatted-sql.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Formatted SQL
----
-
-# Liquibase Formatted SQL
-
-Part of the changes made in the upcoming 2.0 release is supporting the ability to specify changelog files in formats other than XML.
-
-
-As a proof of concept, I added the ability to write your changelog files in specially formatted SQL format rather than XML.
-
-
-You can now write your changelogs like this:
-
- --liquibase formatted sql
- --changeset nvoxland:1
- create table test1 (
- id int primary key,
- name varchar(255)
- );
-
- --changeset nvoxland:2
- insert into test1 (id, name) values (1, 'name 1');
- insert into test1 (id, name) values (2, 'name 2');
-
- --changeset nvoxland:3 (dbms:oracle)
- create sequence seq_test
-
-which, when run, will run three separate changeSets on oracle, and two changesets on all other databases. Note that this is specifying raw SQL, not abstracted liquibase changes like "createTable" that generate different SQL depending on the target database.
-
-You do need to have your file contain "--liquibase formatted sql" on the first line, and delineate your changelogs with the "--changeset AUTHOR:ID" lines.
-
-After the AUTHOR:ID, you can specify any attribute normally available on the or XML tags, including:
-
-- stripComments
-- splitStatements
-- endDelimiter
-- runOnChange
-- runAlways
-- context
-- dbms
-- runInTransaction
-- failOnError
-
-Since the formatted SQL builds the same internal changelog structure as the XML changelogs do, all the normal liquibase functionality (rollback, tag, dbdoc, updateCount, updateSQL, changelog parameters, etc.) are still available.
-
-You can try out this new feature from the current 2.0 snapshot. Let me know if you have any suggestions or problems. I am considering it an early access feature until 2.0 final is released, and there may be changes in the format of this file based on user feedback.
diff --git a/_posts/2010-05-19-looking-for-help-with-maven-configuration.md b/_posts/2010-05-19-looking-for-help-with-maven-configuration.md
deleted file mode 100644
index 1c38444a8..000000000
--- a/_posts/2010-05-19-looking-for-help-with-maven-configuration.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Looking for help with Maven configuration
----
-# Looking for Help with Maven Configuration
-
-Part of the delay of the next 2.0 RC is that I want that release to include a 2.0 snapshot in the maven repository for people to try. Unfortunately, I have determined that my maven skills are not what I need them to be to make this happen, and am hoping I can get some help.
-
-
-If you look at the liquibase source from http://liquibase.jira.com/source/browse/CORE you'll see that we have what is probably an uncommon source configuration--which is the root of a lot of my maven issues.
-
-
-The main source is broken up into three major sub-modules:
-
-
-- liquibase-core
-- liquibase-core-jvm
-- liquibase-maven-plugin
-
-
-
-each with its own pom.xml. The general idea is that the liquibase-core and liquibase-core-jvm modules are compiled and combined into a single jar file that is released as liquibase-core.jar while the liquibase-maven-plugin module is released independently. There is a liquibase-dist module that attempts to bind everything together in to liquibase-core, but I'm not sure if it is really doing it all correctly.
-
-
-
-Prior to 2.0, liquibase was build using Ant and we do have a repository on sourceforge that is rsynced with the central maven repository. The old process used an ant task to update a local copy of that maven repository and I would upload the new/changed files to the sourceforge site manually.
-
-
-The main questions that I know of currently are:
-
-1. How do I get maven to create the "liquibase-core " module to release to the maven repository?
-1. What is the best way to create and release it? I would like the process to be based on builds from the build server, not based on building the modules locally
-1. What improvements should I make to the module structure?
-1. Is what I am trying to do too much for maven's preferred way of doing things?
-1. What should I be doing to help OSGi support?
-
diff --git a/_posts/2010-06-09-liquibase-2-0-will-switch-to-the-apache-2-0-license.md b/_posts/2010-06-09-liquibase-2-0-will-switch-to-the-apache-2-0-license.md
deleted file mode 100644
index db12fc44b..000000000
--- a/_posts/2010-06-09-liquibase-2-0-will-switch-to-the-apache-2-0-license.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 Switch to Apache 2.0 License
----
-# Liquibase 2.0 Apache 2.0 License
-
-As of the 2.0 release of Liquibase, we will switch to being licensed under the Apache License, version 2.0 rather than the LGPL.
-
-
-The reason for the change is to make Liquibase more business friendly, especially with regards to being able to write extensions without worrying about license requirements that may be imposed by the LGPL. I'll work on updating the license information on the web site and in the 2.0 codebase over the next few days. Let me know if you have any questions.
diff --git a/_posts/2010-07-11-liquibase-2-0-rc2-released.md b/_posts/2010-07-11-liquibase-2-0-rc2-released.md
deleted file mode 100644
index 1807b09c2..000000000
--- a/_posts/2010-07-11-liquibase-2-0-rc2-released.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 RC2 Released
----
-# Liquibase 2.0 RC2 Released
-
-Wow, it has been a very long time since RC1, but we finally are ready for RC2. It can be downloaded from the Liquibase download page like usual, and I have created an upgrade to 2.0 guide.
-
-
-There have been a lot of bug fixes between RC1 and RC2 as well as some additional internal code structure and release process work done. The full 2.0 feature list is being built on the wiki.
-
-
-Please test it out and let us know if you have any questions or problems. My goal is for this to be the final RC and to have 2.0 final out in a week or two. The maven plugin is not yet released to the maven repository as I am switching our primary location to Sonatype and that is not fully configured yet. Hopefully in the next couple days it will be available. I will also be working on testing the grails plugin with 2.0 over the next few days and will release an updated version soon.
diff --git a/_posts/2010-07-11-lower-case-b.md b/_posts/2010-07-11-lower-case-b.md
deleted file mode 100644
index e2403498a..000000000
--- a/_posts/2010-07-11-lower-case-b.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Lower Case B
----
-# Lover Case B
-
-I was never a huge fan of the upper case B in "Liquibase" but had gone along with it since that was how it was. However, I've decided now that it bugs me too much, and so I am officially changing the product name to "Liquibase" with a lower case B.
-
-
-I changed some of the documentation and all uses in the code. If you find a documentation page with the old capitalization, please fix it up.
diff --git a/_posts/2010-07-27-liquibase-2-0-rc3-released.md b/_posts/2010-07-27-liquibase-2-0-rc3-released.md
deleted file mode 100644
index 9dfe3a796..000000000
--- a/_posts/2010-07-27-liquibase-2-0-rc3-released.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 RC3 Released
----
-# Liquibase 2.0 RC3 Released
-
-2.0 RC3 is now available. Like always, you can download it from the Liquibase download page
-
-
-RC3 includes:
-
-
-- Bug fixes, including a change to how classes are loaded which should make it work better in application servers.
-- The first 2.0 RC build that is pushed to the maven repository. We switched to pushing our jars to a new location, so if they don't sync with the central repository, let me know
-
-
-The 2.0 features and 2.0 upgrade notes are still being added to.
-
-As usual, let us know if you have any questions or problems
diff --git a/_posts/2010-08-02-liquibase-2-0-rc4-released.md b/_posts/2010-08-02-liquibase-2-0-rc4-released.md
deleted file mode 100644
index fa858dc97..000000000
--- a/_posts/2010-08-02-liquibase-2-0-rc4-released.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 RC4 Released
----
-# Liquibase 2.0 RC4 Released
-
-2.0 RC4 is now available. Like always, you can download it from the Liquibase download page
-
-
-The main changes in RC4 are improvements to the Maven POM configuration, and a change to how Liquibase classes and extensions are found and loaded.
-
-
-The 2.0 features and 2.0 upgrade notes are still being added to as well.
-
-
-As usual, let us know if you have any questions or problems
-
-
-*NOTE: There appears to be a bug, at least in the command line version. I'm looking into it...*
diff --git a/_posts/2010-08-03-liquibase-2-0-rc5-released.md b/_posts/2010-08-03-liquibase-2-0-rc5-released.md
deleted file mode 100644
index a73adf501..000000000
--- a/_posts/2010-08-03-liquibase-2-0-rc5-released.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 RC5 Released
----
-# Liquibase 2.0 RC5 Released
-
-Liquibase 2.0 RC5 is now available. It is purely a bug fix for a blocker bug with the ServiceLocator in RC4.
-
-
-You can download it from the Liquibase download page
diff --git a/_posts/2010-10-04-liquibase-2-0-rc6-is-released.md b/_posts/2010-10-04-liquibase-2-0-rc6-is-released.md
deleted file mode 100644
index c2759e554..000000000
--- a/_posts/2010-10-04-liquibase-2-0-rc6-is-released.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 RC6 Released
----
-# Liquibase 2.0 RC6 Released
-
-Hopefully the last RC release before 2.0. As always, you can download it from the Liquibase download page.
-
-
-If you find any issues or have any questions, please let us know on the user forum. See the the 2.0 feature list and 2.0 upgrade notes pages for more information on the 2.0 release in general.
diff --git a/_posts/2010-11-08-liquibase-2-0-rc7-now-available.md b/_posts/2010-11-08-liquibase-2-0-rc7-now-available.md
deleted file mode 100644
index 12dbcf086..000000000
--- a/_posts/2010-11-08-liquibase-2-0-rc7-now-available.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 RC7 Now Available
----
-# Liquibase 2.0 RC7 Now Available
-
-I know I was hoping that RC6 would be the last, but there were enough bugs/changes found that we need another RC build....
-
-
-As usual, you can download the latest RC from the Liquibase download page and report issues to https://liquibase.org/forum.
-
-
-There was a change to how we compute checksums from RC6 to RC7, so it will be a good chance to test the checksum versioning code introduced in with 2.0, so let us know if you run into any changeSet checksum validation issues
diff --git a/_posts/2011-01-13-new-standard-liquibase-plugin-grails-database-migration.md b/_posts/2011-01-13-new-standard-liquibase-plugin-grails-database-migration.md
deleted file mode 100644
index 216097ff2..000000000
--- a/_posts/2011-01-13-new-standard-liquibase-plugin-grails-database-migration.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: 'New Standard Liquibase Plugin: Grails Database Migration'
----
-# New Standard Liquibase Plugin: Grails Database Migration
-
-Now that the Grails Database Migration plugin has had its first release, I will no longer continue maintaining a the Liquibase Grails plugin past the current 1.9.x series.
-
-
-Although the Database Migration plugin is still at version 0.1, it is based on Liquibase 2.0 and will get the attention and expertise that I was not able to give my version. For those of you using Liquibase 1.9, the old plugin will still be available and updated, but I will not release a new version of it built on Liquibase 2.0+.
-
-
-The Database Migration plugin includes all the functionality in the old plugin, plus support for Groovy DSL changelogs rather than XML, GORM, and more.
diff --git a/_posts/2011-01-13-terradata-extension-now-available.md b/_posts/2011-01-13-terradata-extension-now-available.md
deleted file mode 100644
index d5a68a7db..000000000
--- a/_posts/2011-01-13-terradata-extension-now-available.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Teradata Extension Now Available
----
-# Teradata Extension Now Available
-
-Teradata support is now available as an extension for Liquibase 2.0. The extension was created by Xavier Poinsard and can be downloaded from https://liquibase.jira.com/wiki/display/CONTRIB/Teradata+extension
-
-
-For more information on available Liquibase extensions and how to write your own, see the extension portal
diff --git a/_posts/2011-01-27-liquibase-2-0-officially-released.md b/_posts/2011-01-27-liquibase-2-0-officially-released.md
deleted file mode 100644
index a43fc0aa1..000000000
--- a/_posts/2011-01-27-liquibase-2-0-officially-released.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0 Officially Released
----
-# Liquibase 2.0 Officially Released
-
-At long last, Liquibase 2.0 has been released. For those of you watching closely, you know that 2.0.0 was actually released December 19th, but I wanted to give it a couple weeks (and a 2.0.1 release) before making the official announcement. Liquibase 2.0 has been a long time coming, but I am very proud of it. The most recent version (now 2.0.1) is available from the Liquibase download page along with the v2.0 upgrade guide.
-
-
-With version 1.9, Liquibase had hit the point where it had a growing user base and 90% of the functionality that developers needed to manage their databases. As I was looking at what to add for version 1.10, it was becoming clear that everyone wants a different (and often contradicting) final 10%. One team wants CLOBS to match to a UTF-8 compliant datatype, another wants them to be full text indexable. One team wants logging using slf4j, another wants log4j. And don't forget the biggest war of all: XML changesets vs. the XML-haters. Add to this a tool with complex (and sometimes confusing) functionality and there were two obvious requirements for the future of Liquibase: Extensibility and Community.
-
-
-### Extensibility
-
-Feature-wise, the biggest change with Liquibase 2.0 is the new extension system. The goal of the Liquibase extension system is to allow end users to modify and mold Liquibase to suite their particular development needs. While 1.9 and before included features like custom change classes, `` and changelog parameters, it wasn't a true plugin system. With 2.0, we introduced the ability to create custom java classes that will replace or augment virtually all areas of Liquibase's execution including changelog parsing, database support, available refactorings, generated SQL, logging and more.
-
-
-Now, if you don't like that the generated CREATE TABLE SQL does not include "ENGINE=INNODB", you can create a subclass of CreateTableGenerator to modify it. If you would rather use a different logger you can create a subclass of AbstractLogger. If you don't like XML, you can write a new changelog parser (there are now groovy, scala, and clojure versions underway).
-
-
-The general pattern for all extensions is to create a subclass for an existing Liquibase class or interface and override the *public void getPriority()* method. At runtime, Liquibase will find all classes that implement a given class/interface and choose the one with the highest value from getPriority(). Registering your extension only requires you to put your class in a sub-package of liquibase.ext.
-
-
-### Community
-
-
-Although there is often conflicting requirements behind extensions, there is also many groups that need the same problems solved. To help facilitate the sharing and development of Liquibase extensions, we have created the Liquibase Extension Portal where anyone can post and share extensions they have created, including using our subversion and/or bug tracking if needed.
-
-
-Beyond the extension portal, there have been several other "improve the Liquibase community" changes since 1.9 was released, including:
-
-
-- Replacing the mailing lists with a forum system
-- Changed from LGPL license to the more permissive Apache 2.0 license
-- Switched to Jira for bug and feature tracking
-- Introduced an official Liquibase training and support channel
-- Moved SVN for better source browsing and Jira integration
-- Created an announcement mailing list/newsletter (see https://liquibase.org sidebar to subscribe)
-- Major code refactoring/simplification effort to make a smaller learning curve to contributing code
-
-### But Wait, There's More!
-
-
-Beyond the big goals of extensibility and community (and the bug fixes), there is also important new functionality in the core Liquibase library including:
-
-
-- SQL-based Changelogs
-- Informix support
-- Ability to specify target changelog parameters to particular databases and/or context
-- Ability to specify target modifySql to particular contexts
-- Expanded use of changelog properties, including in preconditions and SQL text
-- Performance improvements
-
-### The Future
-
-
-With the official release of Liquibase 2.0, the plan is to go back to a more standard release schedule. That means that 2.1 will not take 2 years... The jump from 1.9 to 2.0 had a lot of pieces to move around but the primary reason for the long release schedule was ensuring that the internal Liquibase API will be stable going forward for end users to code extensions against without fear of breaking changes.
-
-
-Going forward, Liquibase development will be broken into two areas: work on the core library and work on extensions. While the extension system is great for end users, it will also help us to build deeper support for particular databases without trying to force database-specific functionality into the main library, iterate new and experimental features independently of the main library, and add take advantage of 3rd party libraries without adding a required dependency for everyone. This will allow the core Liquibase library to be better focused on providing a solid feature-set that is common to all databases and users.
-
-
-I have already began some work on 2.1 which is primarily targeted at improving the database diff support which will allow the hibernate integration to improve as well as changelog generation for existing databases. Work beyond 2.1 will, like usual, be driven by user request. I would like to get back to the .net and Liquibase IDE proof-of-concepts I had began as well. There is also additional community improvements I would like to investigate including a less spam-attracting forum and possibly moving from SVN to github.
-
-
-As always, let us know if you have any questions or suggestions, and thanks to everyone that contributed code, bug reports, and help during the 2.0 development.
diff --git a/_posts/2011-02-14-new-liquibase-forum.md b/_posts/2011-02-14-new-liquibase-forum.md
deleted file mode 100644
index 0b7ad7553..000000000
--- a/_posts/2011-02-14-new-liquibase-forum.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: New Liquibase Forum
----
-# New Liquibase Forum
-
-If you visit https://liquibase.org/forum you will notice that it looks completely different. We were getting hit pretty hard with spam over the last few months on the old forum and I concluded that we could not stop it with the current simple machines software. As a result, we have moved to a Zoho-based forum.
-
-
-There were suggestions to simply go with Google Groups, but in the end Zoho provided question-tracking features I liked as well as the ability to import in all the old forum topics and so I went with them.
-
-
-Please check out the new forum and let me know if you have any suggestions or questions on it.
diff --git a/_posts/2011-03-15-clojure-wrapper-for-liquibase-now-available.md b/_posts/2011-03-15-clojure-wrapper-for-liquibase-now-available.md
deleted file mode 100644
index 8c795d439..000000000
--- a/_posts/2011-03-15-clojure-wrapper-for-liquibase-now-available.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Clojure wrapper for Liquibase
----
-# Clojure Wrapper for Liquibase Now Available
-
-Kumar Shantanu has implemented a Clojure DSL/wrapper for Liquibase which is has reached version 0.1. It is available at https://bitbucket.org/kumarshantanu/clj-liquibase/src. One more option for all you XML-haters out there :)
-
-
-Nathan
diff --git a/_posts/2011-04-21-netbeans-liquibase-plugin-available.md b/_posts/2011-04-21-netbeans-liquibase-plugin-available.md
deleted file mode 100644
index b2d1f2ca4..000000000
--- a/_posts/2011-04-21-netbeans-liquibase-plugin-available.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: NetBeans Liquibase Plugin Available
----
-# NetBeans Liquibase Plugin Available
-
-For NetBeans users, there is a Liquibase plugin now available.
-
-
-The current, 0.2 version implements rudimentary support and concentrates on the most needed functionality.
-
-
-Features:
-
-
-- Database connections stored in the Database Explorer plugin, so the developer doesn't have to separately maintain the registry of connections.
-- Executing a changeset by simply selecting it in the File or Project explorer windows and call the execution from a context menu action. The database connection can be selected during the execution
-- A formatted log is displayed in the Output Window about the execution of the changeset, so the developer is properly informed if the changeset execution has failed.
-- Custom icon for the Liquibase changeset files, so they can better distinguished from the ordinary files.
-
-
diff --git a/_posts/2011-07-11-liquibase-source-moved-to-github.md b/_posts/2011-07-11-liquibase-source-moved-to-github.md
deleted file mode 100644
index eab85d886..000000000
--- a/_posts/2011-07-11-liquibase-source-moved-to-github.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Source Moved to Github
----
-# Liquibase Source Moved to Github
-
-For those of you watching and/or contributing to the Liquibase source code, the repository has now moved from the old subversion repository at liquibase.jira.com to https://github.com/liquibase/liquibase.
-
-
-Liquibase extensions maintained by the main Liquibase team have also been moved to the liquibase github group at https://github.com/liquibase.
-
-
-If you have any questions, feel free to ask on the Liquibase development forum
diff --git a/_posts/2011-09-16-liquibase-2-0-2-released.md b/_posts/2011-09-16-liquibase-2-0-2-released.md
deleted file mode 100644
index 0a1590b42..000000000
--- a/_posts/2011-09-16-liquibase-2-0-2-released.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0.2 Released
----
-
-# Liquibase 2.0.2 Released
-
-Liquibase 2.0.2 has been released. It is primarily a bugfix release on the 2.0.1 release and can be downloaded from the Liquibase download page.
-
-
-Visit the forum with any comments or questions. Release notes are available from liquibase.jira.com
-
-
-With the 2.0.2 release, main development will shift to the 2.1 release. Liquibase 2.1 planning has begun with this forum post
diff --git a/_posts/2011-10-10-liquibase-2-0-4-released.md b/_posts/2011-10-10-liquibase-2-0-4-released.md
deleted file mode 100644
index 2123dcb5d..000000000
--- a/_posts/2011-10-10-liquibase-2-0-4-released.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0.3 Released
----
-# Liquibase 2.0.3 Released
-
-2.0.3 is a very small update, mainly fixing the maven repository and the end of line char in the command line unix shell script.
-
-
-Other bugs fixed are:
-
-
-- Allow Changelog Parameters in raw SQL changesets and formatted SQL changelogs
-- Sybase NUMERIC issue
-- An issue with DB2 and defaultSchema
-
diff --git a/_posts/2012-02-24-liquibase-3-0-status-update.md b/_posts/2012-02-24-liquibase-3-0-status-update.md
deleted file mode 100644
index 5f20d81d3..000000000
--- a/_posts/2012-02-24-liquibase-3-0-status-update.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0 Status Update
----
-# Liquibase 3.0 Status Update
-
-It has been a while since the last Liquibase release, and I wanted to give a quick status update.
-
-
-The main thing I have been working on is the next version of Liquibase, which I am going to call 3.0.0. For those of you following along, the goal of 2.0 was to create an extensible system on top of liquibase as well as solidify the liquibase APIs for anyone wanting to integrate liquibase into their applications. Due to the size of that undertaking, the "diff" support did not get the same API cleanup and extensibility system in the 2.x release.
-
-
-For the last several months I have been going through the diff side of the codebase, adding things such as:
-
-
-- Standardized ways to specify mappings between "standard types" and "database specific types" in changeslogs
-- Support for differentiation between catalogs and schemas
-- The ability to add custom database objects to extract and compare in the snapshot/diff process
-- The ability to change how database objects are extracted and compared
-- Support for annotations in defining Change classes to make for easier subclassing
-- Support for custom diff reporting formats
-- Ability to handle multiple cross schema and catalog references in diffs
-
-
-
-All-in-all I have about 400 changed files in my local repository that I have been waiting to push up to github until it is in a coherent state. I keep thinking "I'm sure it will be ready by next week" but keep finding more I would like to get done first. Because my local repository is so different than the github repository, I have not been bringing in the pull requests as I normally would. I will get to those once I get my changes pushed since I tend to do some modifications to the commits as part of the integration process.
-
-
-
-I am calling the next version 3.0 rather than 2.1 because of the potentially breaking changes between 2.0 and 3.0. From an end-user standpoint, there will be little to no changes in the changelog format. Most breaking changes are in the internal liquibase APIs for those integrating liquibase and/or writing extensions. More information will be made available on breaking changes closer to release date.
-
-
-Besides the code, I spent time lately dealing with defacement issues on liquibase.org and blog.liquibase.org. Because of this attack and earlier spam scripts that abused the wiki system, I am going to move the documentation and site from the current dokuwiki system to github. This has the advantage of better performance, the ability to manage branches of the documentation, and the ability to include an offline version of the manual with each release. Documentation changes will require a github pull request rather than the simpler wiki-style direct editing, however.
-
-
-My planned timeline for 3.0 is to commit what I have within the next week or so, then merge in the pull requests and create a "3.0 alpha 1" release. I moved around a lot of database-specific code that will take a while for me to test and would like to get some feedback from the community as soon as possible on new bugs or regressions that were introduced by the changes. I will make an announcement when the first 3.0 release is available for testing.
-
-
-
-
-
-
diff --git a/_posts/2012-04-19-liquibase-2-0-4-released-2.md b/_posts/2012-04-19-liquibase-2-0-4-released-2.md
deleted file mode 100644
index 960af8dc2..000000000
--- a/_posts/2012-04-19-liquibase-2-0-4-released-2.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0.4 Released
----
-# Liquibase 2.0.4 Released
-
-2.0.4 has been released. This is primarily a bug fix release during the main development on 3.0, but does include a few enhancements as well.
-
-
-Download from the Liquibase download page.
-
-
-### New features:
-
-
-- LoadUpdate support for H2
-- Support ${} params in sql files
-- Ability to load blob/clob data from files
-- Full release notes: https://liquibase.jira.com/secure/ReleaseNote.jspa?projectId=10020&version=10160
diff --git a/_posts/2012-05-02-liquibase-2-0-5-released.md b/_posts/2012-05-02-liquibase-2-0-5-released.md
deleted file mode 100644
index 75bac6ffc..000000000
--- a/_posts/2012-05-02-liquibase-2-0-5-released.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 2.0.5 Released
----
-
-# Liquibase 2.0.5 Released
-
-2.0.5 has been released. This is to fix a couple regressions introduced in 2.0.4.
-
-
-Download from the Liquibase download page.
-
-
-Bug Fixes:
-
-
-- Removed new load blob/clob data from files feature
-- Fixed linux distribution shell script
-- Command line updateSQL output is once again going to STDOUT
-
-**Full release notes**: https://liquibase.jira.com/secure/ReleaseNote.jspa?projectId=10020&version=10360
-
diff --git a/_posts/2013-02-13-liquibase-3-0-beta-1.md b/_posts/2013-02-13-liquibase-3-0-beta-1.md
deleted file mode 100644
index dd744bfe2..000000000
--- a/_posts/2013-02-13-liquibase-3-0-beta-1.md
+++ /dev/null
@@ -1,57 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0 Beta 1
----
-
-# Liquibase 3.0 Beta 1
-
-Although it has been far too long since the last liquibase release, that is not from a lack of work. I've been hard at work at a major update that has been stuck in the "I think I'll have it wrapped up next month" phase for over a year at this point. That is a topic for a future blog post, though…
-
-
-I am, however, very pleased to announce Liquibase 3.0, beta 1. There is definitely a reason it is labeled as "beta" rather than "RC" as there is still a lot of work to do on documentation, API finalization, and bug fixes. In particular, my roadmap for 3.0 beta 1 -> 3.0.0 final is:
-
-
-- Vet Liquibase API changes. The goal of the 2.0 release was to open Liquibase for integration and extensibiliy and I want a strong, stable API. Version 3.0 greatly expands the scope of how you can mold and shape liquibase, and I want to make sure that the APIs liquibase exposes are easy to use yet will support future features as well without breaking changes.
-- Documentation update. The liquibase.org website is a bit dated and the there are many holes in the documentation. I am going to update that with a new github-based site and ensure it is up to date with what is new in 3.0 (and things missed from previous releases)
-- Jira cleanup. http://liquibase.jira.com has gotten to be a mess in 3.0 with many duplicated issues, issues that have already been resolved, simple things that can be fixed still in 3.0 mixed with larger changes that will have to go in 3.1+, etc. I need to go through the list to make sure simple and/or blocker bugs are resolved and things that can wait for 3.1 are pushed out.
-- Testing. I've primarily tested against Mysql, Oracle, SqlServer, HSQL, and H2. I need to make sure the other supported databases are working as well.
-
-
-
-My hope is that 3.0.0 beta represents a feature complete 3.0 version, but the final walk through of features, bugs and extension points will probably find some additional larger changes to make. My plan is to have a new beta roughly bi-weekly until the 3.0.0 release in early April. However, "it's software, so it can do anything except ship on time".
-
-### High level changes in 3.0
-
-
-- Dropped Java 1.5 support
-- Major changes in diff and snapshot log
-- Support for "catalogs" in addition to schemas
-- Separated "diff" and "snapshot" logic for better modularity
-- Extension support for LockService
-- Extension support for defining new DataTypes
-- Extension support for defining new snapshot DatabaseObjects
-- Extension support for defining new Snapshot log
-- Extension support for how to compare DatabaseObjects
-- Better extension support for changelog generation
-- More object types are snapshotted
-- Changes can provide metadata helpful for IDE and other integrations
-- Added ability for objects to control how they are serialized via the LiquibaseSerializable interface
-- Can define tablespace for liquibase tables
-- Performance improvements
-- Ability to specify sequences to read values from on ``
-- Improve OSGi support
-- Support preconditions in formatted SQL
-- Maven supports generateChangeLog
-- Better support for case sensitive databases
-- API cleanup
-- Ability to SKIP columns in a CSV file
-- Improved Informix support
-- Support JDBC escape syntax in SQL
-- Added futureRollbackCountSQL
-- Support ${} params in formatted SQL
-- Many bug fixes
-
-### Download
-
-As always, you can download the release from http://liquibase.org/download and direct any comments or questions for https://forum.liquibase.org
diff --git a/_posts/2013-03-28-liquibase-3-0-beta-2.md b/_posts/2013-03-28-liquibase-3-0-beta-2.md
deleted file mode 100644
index aed522290..000000000
--- a/_posts/2013-03-28-liquibase-3-0-beta-2.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0 Beta 2
----
-# Liquibase 3.0 Beta 2
-
-Liquibase 3.0 beta 2 is now available.
-
-
-Major changes since beta 1 include:
-
-
-- Support for YAML and JSON formatted changelogs (see below)
-- Support for excluding databases in dbms attribute (see below)
-- Support for setting the dbms attribute on sql and sqlfile changes
-- Can generate rollback script file on startup with SpringLiquibase
-- Improved UTF8 support
-- Improvements to case-sensitive database support
-- Bugfixes
-
-### Excluding from dbms list
-
-The dbms attribute now supports prepending a database name with "!" to specify which databases a changeset should not run on. For example: ``
-
-### JSON and YAML changelog support
-
-
-For all you XML-haters out there, Liquibase not natively supports JSON and YAML formatted changelogs. The syntax and tags are very similar between the JSON, YAML and XML formats.
-
-
-YAML example: https://raw.github.com/liquibase/liquibase/master/liquibase-integration-tests/src/test/resources/changelogs/yaml/common.tests.changelog.yaml
-
-
-JSON example: https://raw.github.com/liquibase/liquibase/master/liquibase-integration-tests/src/test/resources/changelogs/json/common.tests.changelog.json
-
-
-If you chose to use YAML or JSON format, you will need to include snakeyaml 1.12 in your classpath.
-
-
-I'm continuing to work on shifting the documentation to github from the current wiki, and while there is still much more to do, you can at least see YAML and JSON change syntax example at http://liquibase.github.com/documentation/changes/add_auto_increment.html.
-
-
-### Download
-
-
-As always, you can download the release from the
-Liquibase download page and direct any comments or questions for https://forum.liquibase.org
diff --git a/_posts/2013-05-06-liquibench-kickstarter-project.md b/_posts/2013-05-06-liquibench-kickstarter-project.md
deleted file mode 100644
index 2d8550f60..000000000
--- a/_posts/2013-05-06-liquibench-kickstarter-project.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibench Kickstarter Project
----
-# Liquibench Kickstarter Project
-
-Looking for an easier way to use Liquibase?
-
-
-
-I recently launched a "Liquibase IDE" Kickstarter project called "Liquibench" at http://www.kickstarter.com/projects/149257506/liquibench with the goal of making Liquibase more Intellij/Eclipse/Resharper and less XML-editor+command-prompt.
-
-
-
-I've started similar projects over the years, but to finish and support them took far more time than I was able to provide. My hope with this project is to jump-start it as a commercial offering in order to provide the effort required to build it and the ability to support it long term.
-
-
-
-If you are interested in such a tool, please consider helping to fund the project. A successful kickstarter project will ensure it gets built, prove the market, and greatly expand the team dedicated to Liquibase.
-
diff --git a/_posts/2013-05-20-liquibase-3-0-rc-1.md b/_posts/2013-05-20-liquibase-3-0-rc-1.md
deleted file mode 100644
index b950f86bc..000000000
--- a/_posts/2013-05-20-liquibase-3-0-rc-1.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0 RC 1
----
-# Liquibase 3.0 RC 1
-
-Since the 3.0 beta 2 release, I have been focused on the new liquibase.org website, bug fixes, performance improvements, API cleanup and additional automated test creation and fixup.
-
-
-### Work remaining in the final push to 3.0.0:
-
-
-- Finish documentation of new 3.0 features (including a "what's new in 3.0" list)
-- Finish Java API cleanup/documentation
-- Clean up "fix in 3.0.0" Jira list that includes many issues that have already been fixed and others that will not make it for 3.0.
-- Any remaining showstopper bugs found in RC1
-
-
-
-My hope is to have 3.0.0 released in the first week of June.
-
-
-
-### Download
-
-
-As always, you can download the release from the
-Liquibase download page and direct any comments or questions for https://forum.liquibase.org
-
-
-The 3.0 RC1 release is the first 3.0 release that is available through the maven repository as well. It should be working it's way through the mirroring process now.
diff --git a/_posts/2013-06-04-liquibase-3-0-rc-2.md b/_posts/2013-06-04-liquibase-3-0-rc-2.md
deleted file mode 100644
index 9d131305c..000000000
--- a/_posts/2013-06-04-liquibase-3-0-rc-2.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0 RC 2
----
-# Liquibase 3.0 RC 2
-
-It has taken longer to work through the remaining 3.0 bug list than I was hoping, and so do not have the 3.0 GA finished yet, but RC2 is now available.
-
-
-### Changes since RC1 include:
-
-
-- All automated tests now pass
-- Diff support: Improved detection and handling of changed attributes, like data type size
-- Several fixes for DB2, Oracle, Postgres, MySQL and HSQL
-- DBDoc logic now working again
-- Better cleanup of temp files and directories
-- Whitespace and newlines are now not taken into account for `` checksums
-
-
-
-### Download
-
-
-
-As always, you can download the release from the Liquibase download page or through the maven repository. Direct any comments or questions for https://forum.liquibase.org
diff --git a/_posts/2013-06-18-liquibase-3-0-0-released.md b/_posts/2013-06-18-liquibase-3-0-0-released.md
deleted file mode 100644
index c5d18c05c..000000000
--- a/_posts/2013-06-18-liquibase-3-0-0-released.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0.0 Released
----
-# Liquibase 3.0.0 Released
-
-At long last, I'm happy to announce that Liquibase 3.0.0 is finally out!
-
-
-There has been a lot of changes and a lot of work put into 3.0, but the major highlights are:
-
-
-### Additional extension support
-
-
-Starting with Liquibase 2.0, moving to a plugin/extension model has been a major focus of development. With 3.0 we focused on adding extension support for the database snapshot and comparison logic as well as for the DatabaseChangeLogLock code. The new extension support gives the ability to dynamically add snapshot support for additional database object types, control how those types are compared across databases, modify the logic used for comparing standard liquibase types, manage how fixes for differences in new and existing types are represented in generated changelogs, and much much more.
-
-
-The general strategy for Liquibase is to have the core library easily support the 80% of functionality that is common across databases and across users, with built in features like contexts, changelog parameters, and modifySql that will cover up to 95% of use cases. Extensions will address the final 5% of use cases that are always very company specific and often contradictory to what other users expect.
-
-
-The release timelines for 2.0 and 3.0 were much longer than I would have liked in large part because I was trying to build up the architecture to support the extension points people need. Now that 3.0 is out, the plan is to go back to a much smaller release cycle with more manageable feature changes and bug fixes while also better seeding and managing the community extensions.
-
-
-For more information on extension support in Liquibase, visit the extension portal. Documentation is still lighter than I would like, but more will be coming.
-
-
-### Additional integration support
-
-
-For those integrating with the Liquibase Java API, there is now more metadata available from Change classes as well as separated and better organized "diff" and "snapshot" logic.
-
-
-### End user improvements
-
-
-For the normal user, Liquibase 3.0.0 adds:
-
-
-- Support for preconditions in formatted SQL changelogs
-- YAML and JSON changelog support
-- Support for "catalog" attributes in all applicable change commands in addition to the existing "schema" attribute
-- Better support for case sensitive databases
-- Maven now supports the generateChangeLog command
-- Ability to specify sequences to read values from on ``
-- Performance improvements
-- Support ${} params in formatted SQL
-- Improved Informix support
-- Improved OSGi support
-- Improved UTF8 support
-- Can now use JDBC escape syntax in SQL
-- "dbms" attribute supports NOT syntax (using '!')
-- Added futureRollbackCountSQL command
-- Tablespace can be defined for liquibase tables
-- Added ability to SKIP columns in a CSV file
-- Many bug fixes
-
-
-### Upgrading to 3.0
-
-
-
-For the normal Liquibase user, version 3.0.0 is a drop in replacement for any of the 2.x releases. For extension developers and integrators, there has been some changes to the Java APIs that may impact your code. Those changes will be documented. Liquibase 3.0 now requires Java 1.6+.
-
-
-### Downloading 3.0
-
-As always, you can download Liquibase from the Liquibase download page and direct any comments or questions to https://forum.liquibase.org.
-
-
-The raw Jira release notes are available at https://liquibase.jira.com/secure/ReleaseNote.jspa?projectId=10020&version=10020
diff --git a/_posts/2013-06-25-new-branches-simpler-jira-and-updated-developer-documentation.md b/_posts/2013-06-25-new-branches-simpler-jira-and-updated-developer-documentation.md
deleted file mode 100644
index 06c457c40..000000000
--- a/_posts/2013-06-25-new-branches-simpler-jira-and-updated-developer-documentation.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: New Branches, Simpler Jira and Updated Developer Documentation
----
-# New Branches, Simpler Jira and Updated Developer Documentation
-
-Now that 3.0.0 is out, I've cleaned up the Jira process a bit, created more git branches and tried to document it on the liquibase.org site.
-
-
-On the liquibase.org top navigation bar, there is now a "Dev" link that brings to you to information on working with the Liquibase code, GitHub and Jira.
-
-
-The branches page describes the the new branching strategy where we have a "next" branch for the next major release and a "#.#.x" branch for each release family for patch releases. You can see it in action now with both 3.0.0 and 3.0.1 in the "3.0.x" branch and already some changes in the "next" branch for 3.1.
-
-
-The Using Jira page describes how we use the various Jira fields. I simplified the Jira process a bit, taking out the "resolved" stage in favor of just "closed", removed fields we were not using, and created additional components for better categorization.
-
-
-There is other good information in the new developer section of the site including how to build Liquibase with Maven and I will continue to add more down the road.
diff --git a/_posts/2013-07-12-liquibase-3-0-2-released.md b/_posts/2013-07-12-liquibase-3-0-2-released.md
deleted file mode 100644
index c516ebf7f..000000000
--- a/_posts/2013-07-12-liquibase-3-0-2-released.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0.2 Released
----
-# Liquibase 3.0.2 Released
-
-Liquibase 3.0.2 has been officially released. It is a purely bugfix release. The major issues fixed are:
-
-
-- Indexes and foreign keys were not being correctly handled in the snapshot/diff/generateChangeLog process
-- Exporting data in generateChangeLog did not work
-
-
-
-The full list of resolved issues:
-
-- CORE-1301 - Oracle TIMESTAMPS not exported correctly
-- CORE-1301 - defaultschemaName not used
-- CORE-1315 - Database Objects do not get dropped on DB2
-- CORE-1317 - Not all FK Constraints get dropped on Oracle
-- CORE-1318 - Not all FK Constraints get dropped on SQL Server
-- CORE-1328 - includeAll trying to process invalid file types, should only process valid change log types
-- CORE-1331 - If logicalFilePath attribute is set on databaseChangeLog, I am unable to use relativeToChangelogFile="true" on
-- CORE-1332 - includeAll of changelog files throws duplicate identifiers error
-- CORE-1335 - Data export support broken in 3.0
-- CORE-1336 - AutoIncrement not working with some types
-- CORE-1337 - Problem with changeset defined as runAlways="true"
-- CORE-1339 - NPE on update if default ServiceLocator.packagesToScan is used
-- CORE-1340 - indexExists Changesets throwing PreconditionErrorException instead of PreconditionFailedException
-- CORE-1341 - foreignKeyConstraintExists precondition broken
-- CORE-1344 - addForeignKeyConstraint rejects referencesUniqueColumn
-- CORE-1347 - dropAll function work incorrectly when table has 2 foreign keys
-- CORE-628 - Specify the output encoding that liquibase should use to output data in Maven
-
-
-
-If you were watching closely, you will notice that I forgot to announce 3.0.1 despite the fact that it was released on June 25th. That release included the following bugfixes compared to 3.0.0:
-
-
-
-- CORE-898 - Custom precondition xsd failing
-- CORE-1171 - Maven plugin displaying password in plain text
-- CORE-1320 - Cannot include YAML file
-- CORE-1323 - Conversion from char to SMALLINT is unsupported
-- CORE-1324 - Formatted SQL does not support contexts such as "some-context" or "some/context"
-
-
-
-As always, you can download from the Liquibase download page and the new version should be working its way through the maven repository system. If you have questions or comments you can visit the forums at http://forum.liquibase.org.
-
-
-
-
diff --git a/_posts/2013-08-29-liquibase-3-0-3-released.md b/_posts/2013-08-29-liquibase-3-0-3-released.md
deleted file mode 100644
index a84d35551..000000000
--- a/_posts/2013-08-29-liquibase-3-0-3-released.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0.3 Released
----
-# Liquibase 3.0.3 Released
-
-Liquibase 3.0.3 has been officially released. As always, you can download from the Liquibase download page and the new version should be working its way through the maven repository system. If you have questions or comments you can visit the forums at http://forum.liquibase.org.
-
-
-The 3.0.3 release is primarily a bug fix release, major categories of bugs fixed include:
-
-
-- updateSQL output goes to STDOUT rather than STDERR. *NOTE: This is what people expect, but if you are working around this bug you will have to update your scripts*
-- Fixes around data type parsing and handling
-- Issues with the diff/generateChangeLog logic
-- Informix-specific bugfixes
-
-
-
-There is a new feature in 3.0.3 to control whether schema names are included in the SQL. This is particularly helpful in updateSQL mode to create schema-independent scripts. The new flag is called "outputDefaultSchema" and "outputDefaultCatalog"
-
-
-
-Full Release Notes: https://liquibase.jira.com/secure/ReleaseNote.jspa?projectId=10020&version=10660
-
-
-- CORE-844 - Integer with range limitations handled incorrectly on Oracle
-- CORE-1313 - Unique constraint name is ignored when adding a column
-- CORE-1316 - Column Type COMPUTED in loadData is not implemented correctly (shoud pass a DB Function instead of String to DB).
-- CORE-1327 - renameColumn and renameTable with Sybase
-- CORE-1329 - GenerateChangeLog on MSSQL exports a SMALLINT(5) - smallint does not allow precision
-- CORE-1336 - AutoIncrement not working with some types
-- CORE-1351 - PostgreSql 9 doesnt have datetime data type
-- CORE-1353 - AutoIncrement not working for numeric types
-- CORE-1354 - Sequences get dropped too early
-- CORE-1356 - Unnecessary size specifications on MEDIUMTEXT, TINYTEXT, MEDIUMBLOB, TINYBLOB from generateChangeLog
-- CORE-1358 - Liquibase 3.0.2 writes '3.0.0-SNP' (Snapshot) to 'LIQUIBASE' column instead of '3.0.2'
-- CORE-1362 - Informix fails when schema is not equal catalog
-- CORE-1363 - ForeignKey NPE during dbDoc generation
-- CORE-1364 - SQL Server incorrect INFORMATION_SCHEMA table case in native query
-- CORE-1366 - Oracle database dbDoc generation performance issues
-- CORE-1367 - updateSQL generates an empty file using standard output in 3 version
-- CORE-1369 - Whitespace in author in SQL formatted changelog causes that migration to be silently skipped
-- CORE-1370 - Oracle doesnt have DATETIME datatype
-- CORE-1371 - MySQL syntax error is thrown if schema name contains hyphens
-- CORE-1372 - Version Command Line Argument Incorrect
-- CORE-1373 - dropAll attempts to drop objects in other schemas under Oracle
-- CORE-1375 - "group" is not included as a reserved word
-- CORE-1377 - liquibase version says 3.0.0-SNP
-- CORE-1380 - ^M present in liquibase unix running file (from jar on maven repo)
-- CORE-1381 - DropAll: Not working with MsSql
-- CORE-1383 - Error attempting to re-create databasechangeloglock on second liquibase run if running in Oracle under SYSTEM user
-- CORE-1387 - dropAll fails with oracle since version 3.0.2
-- CORE-1388 - MSSQLServer: 'REAL' dataype is returned with unnecessary size modifier during generateChangeLog
-- CORE-1389 - AddLookupTable fails when using QUOTE_ALL_OBJECTS
-- CORE-1394 - additionalInformation lost in DataTypeFactory.fromDescription()
-- CORE-1395 - Bug in MSSQLDatabase.getViewDefinition()
-- CORE-1396 - Liquibase is loosing indices on foreign key columns
-- CORE-1397 - Informix DB: Size of VARCHAR more than 255
-- CORE-1398 - Missing or unexpected unique constraint not found on Postgres
-- CORE-1402 - Custom preconditions not passing XML validation
-- CORE-1403 - Default schema not correct when using ``
-- CORE-1405 - SpringLiquibase not closing connection if rollback exception
-- CORE-1406 - MySQL loadUpdateData using literal values for update
-- CORE-1408 - NVarcharType on Derby Fails
-- CORE-1413 - NPE in changeSetExecuted precondition in changelog-level preconditions
-- CORE-1414 - Improve error handling in empty databasechangeloglock tables
-- CORE-1417 - generateChangeLog failed
-- CORE-1418 - Foreign Key changes not detected in snapshot process
-- CORE-1241 - Remove schema name from SQL generated when running updateSQL
-- CORE-1412 - UpdateSQL should write to stdout not stderr
-
-
-
-
diff --git a/_posts/2013-09-06-liquibase-3-0-4-released.md b/_posts/2013-09-06-liquibase-3-0-4-released.md
deleted file mode 100644
index 1f33ba7fd..000000000
--- a/_posts/2013-09-06-liquibase-3-0-4-released.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0.4 Released
----
-# Liquibase 3.0.4 Released
-
-There was a null pointer issue that was tripping up enough people with 3.0.3 that I created a small 3.0.4 release to address the issue.
-
-
-The issues fixed are:
-
-
-- CORE-1423 - NPE in ForeignKeyComparator
-- CORE-548 - GenerateChangeLog generates invalid XML/SQL for mysql tables with autoincrement and compound PKs
-
-
-
-with CORE-1423 being the one most people were running into.
-
-
-
-You can download 3.0.4 from the Liquibase download page and through the maven repository system once it gets mirrored through.
diff --git a/_posts/2013-09-24-liquibase-3-0-5-released.md b/_posts/2013-09-24-liquibase-3-0-5-released.md
deleted file mode 100644
index 8e39cd3f9..000000000
--- a/_posts/2013-09-24-liquibase-3-0-5-released.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0.5 Released
----
-# Liquibase 3.0.5 Released
-
-### Performance
-
-
-The major focus of this release is performance improvements:
-
-
-- Startup time is significantly improved for larger databases
-- Preconditions now snapshot far less of the database
-- Running generateChangeLog on a test MySQL database with over 4000 tables went from crashing after an hour to completing in 30 seconds. Even an Oracle database with the same structure finished in a couple minutes.
-
-
-
-If you are still seeing any unexpected performance problems, file a bug report
-
-
-
-You can download 3.0.5 from http://liquibase.org/download and through the maven repository system once it gets mirrored through. If you have any questions or problems, visit the forums or bug tracker
-
-
-### Notable Bugs
-
-
-- Multi-column foreign keys are snapshotted correctly now
-- Improved case-sensitive/insensitive handling
-
-
-
-### Potential Gotchas
-
-
-
-Three bug fixes related to data type translations went into 3.0.5 which may cause issues for people that had been relying on incorrect behavior
-
-
-- MS SQLServer "DATE" columns are now translated to "DATE" rather than SMALLDATETIME
-- MySQL TIMESTAMP columns are now nullable if you do not specify that they should be not null
-- H2 and HSQL CLOB columns are now translated as CLOB rather than LONGVARCHAR
-
-
-
-### Full Change Log
-
-
-
-- CORE-845 - "DATE" data type is deployed as "SMALLDATETIME" in SQL 2008
-- CORE-859 - Nullable TIMESTAMP columns in MySQL are not nullable.
-- CORE-1257 - Oracle: generateChangeLog exports a column of type "NUMBER" as "NUMBER(0,-127)"
-- CORE-1288 - H2 (and other) support for BLOB and CLOB is incorrect
-- CORE-1338 - Using apostrophe in changeset's ID causes SQL error
-- CORE-1360 - Confirmation message of a custom change change is only printed if loglevel is debug
-- CORE-1364 - SQL Server incorrect INFORMATION_SCHEMA table case in native query
-- CORE-1365 - SQL Server: "Database 'dbo' does not exist" error
-- CORE-1401 - Unnecessary snapshot on liquibase update
-- CORE-1415 - Liquibase tables are not detected in oracle running in the SYSTEM schema
-- CORE-1426 - ORACLE: Check for existing tables is case sensitive
-- CORE-1429 - Random order of UniqueConstraint and ForeignKey drop statements
-- CORE-1459 - Maven updateSQL creates databasechangelog table, should only output SQL to do it
-- CORE-1462 - renameColumn with 'text' data type improperly trying to use 'clob' against MySql
-- CORE-1433 - Handle changes in column datatypes in diffChangeLog
-- CORE-1434 - Formatted Changelog format not parsing UTF8 .sql files with BOM
-- CORE-1453 - Multi-column foreign keys not snapshotted correctly
-
-
-
-
-
diff --git a/_posts/2013-10-07-full-speed-ahead-for-liquibase.md b/_posts/2013-10-07-full-speed-ahead-for-liquibase.md
deleted file mode 100644
index 37c280243..000000000
--- a/_posts/2013-10-07-full-speed-ahead-for-liquibase.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Full Speed Ahead for Liquibase
----
-# Full Speed Ahead for Liquibase
-
-For the last two months I have been working full time as an employee with Datical, a startup that is building an enterprise-ready database change management solution on top Liquibase.
-
-
-For me, it has been great because I am now able to devote considerably more time to Liquibase than I ever have before. Since starting Liquibase 7 years ago, I've ran it as a side hobby--spending a few night and weekend hours doing what I can to progress the project. However, as the community and user base has grown it had become difficult to keep pace. You may have noticed that during the 3.0 development timeline, I tended to oscillate between spending all my time writing code without answering any user questions and answering questions without writing code simply because I just didn't have enough time to do everything I needed to.
-
-
-### So what does this change in employment mean for Liquibase? Nothing but good things!
-
-
-Liquibase remains and always will be a freely available open source project. At Datical, we know the value of a strong open source project and community, and my primary responsibility at Datical is to spend as much time on Liquibase as possible in order to improve it for ourselves and for everyone else. In short, my job is to do what I have always done but with more focus and more resources.
-
-
-Now that I have full days worth of time to spend on Liquibase, I have already been able to pick up the pace of Liquibase releases plus keep up with the user forums. It has been great!
-
-
-In the coming months, look for more great changes to Liquibase including:
-
-
-- Improved Documentation
-- More extensions (New Liquibase/Hibernate Extension should be out this week)
-- Regular and frequent releases
-- Easier use
-- Enhanced extension portal
-- More community interaction
-- Streamlined extension writing tools
-- More support and training options and opportunities
-
-
-
-If you would like more information on Datical and DaticalDB you can read their official launch announcement. Or, as always, ask questions in the blog comments, in the Liquibase forum, or contact me directly at nathan.voxland@liquibase.org.
\ No newline at end of file
diff --git a/_posts/2013-10-09-liquibase-3-0-6-released.md b/_posts/2013-10-09-liquibase-3-0-6-released.md
deleted file mode 100644
index ed105079b..000000000
--- a/_posts/2013-10-09-liquibase-3-0-6-released.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0.6 Released
----
-# Liquibase 3.0.6 Released
-
-I'm happy to announce Liquibase 3.0.6 has been released. While the previous release focused on performance, this release was focused on catching up with pull requests and resolving some of the higher value bugs.
-
-
-Some highlights and important notes:
-
-
-- *IMPORTANT:* CDI support has been pulled into a separate liquibase-cdi module. If you are using the CDI integration you need to download the additional jar from http://search.maven.org/#search%7Cga%7C1%7Cliquibase-cdi
-- *IMPORTANT:* The DatabaseChangeLog table no longer contains a primary key which allows us to increase the column sizes without running into index limitations. Author, Id, and Path can all be 255 characters now. This just applies to new changelog tables, though. Liquibase will not adjust an existing changelog table to increase the size.
-- New liquibase.integration.spring.MultiTenantSpringLiquibase integration that runs Liquibase against all database instances in a JNDI subtree
-- Command line supports prompting for command line variables by using PROMPT as a value in the passed arguments. For example "liquibase --username=test --password=PROMPT"
-- Added support for Sybase IQ
-- Fixed Firebird support
-- Fixed include relativeToChangeLog
-- Improvements to Fixes in case (in)sensitive comparison logic
-- Corrections in the Oracle data type snapshot process
-- Better handling of Mysql keywords
-
-
-
-Download Liquibase from the Liquibase download pageor from the Maven repository as it winds its way through the mirror process. Visit the user forums if you have any questions.
-
-
-
-### All Closed Issues
-
-
-- CORE-1088 - Derby fails to create databasechangelog tables
-- CORE-1093 - generateChangeLog fails on MSSQL with coalation CS on views named in lowerCase
-- CORE-1158 - Escaping of reserved keywords in HSQLDB
-- CORE-1170 - loadUpdateData sometimes needs / and sometimes not
-- CORE-1177 - Failure to write a change set to the DATABASECHANGELOG table still applies the change set
-- CORE-1325 - CDI injection does not work with openwebbeans
-- CORE-1343 - Include SQL file with relativeToChangelogFile doesn't work
-- CORE-1378 - Deploy fails on Glassfish
-- CORE-1409 - Package CDI support as a separate module
-- CORE-1436 - loadUpdateData does not escape apostrophes
-- CORE-1437 - Diff is case-sensitive on column names
-- CORE-1440 - Reorg Table gets called before table is created on DB2
-- CORE-1441 - Drop table with cascade does not work on MS SQL Server
-- CORE-1443 - Documentation for liquibase maven logging configuration needs update
-- CORE-1445 - Mysql Reserved Words Not quoted
-- CORE-1449 - Liquibase throws null pointer if included file does not exist
-- CORE-1464 - SQL changelog are not correctly handled (NPE)
-- CORE-1465 - GetViewDefinitionGeneratorMSSQL generates UPPER case view name
-- CORE-1469 - GenerateChangelog not working on Firebird
-- CORE-1470 - Use NUMERIC instead of NUMBER for Sybase ASE
-- CORE-1478 - MySQL keywords 'key' not quoted as a column name
-- CORE-1479 - MySQL 5.5.27 fails to create DATABASECHANGELOG table (Liquibase support fully broken)
-- CORE-1480 - ChangedPrimaryKeyChangeGenerator missing name
-- CORE-1481 - Schema.toString NPE
-- CORE-1482 - Update fails with "Table DATABASECHANGELOGLOCK already exists"
-- CORE-1483 - Boolean values of "false" being incorrectly handled
-- CORE-1488 - Encoding issue with UpdateSQL
-- CORE-1490 - Oracle 10g: Changelog generation changes type NUMBER(\*,0) to NUMBER(22)
-- CORE-1491 - Oracle 10g: changelog generation converts VARCHAR2(n CHAR) to VARCHAR2(n BYTE)
-- CORE-1497 - SQL SERVER: sysdiagram table is captured during generateChangeLog if system diagrams are enabled.
-- CORE-1499 - null appearing in liquibase maven output
-- CORE-1500 - Snapshots do not order objects alphabetically
-- CORE-1501 - Incorrect SQL generated for default column value in PostgreSQL for text columns
-- CORE-602 - Increase the default size of the FILENAME column
-- CORE-1475 - Support entering password(s) interactively on the command line
-- CORE-1477 - Support overriding LockService changeLogWaitTime
-- CORE-1485 - Extract CDI support into a separate module
-- CORE-1492 - DatabaseChangelog Description useless
-- CORE-1502 - CLONE - UpdateSQL needs to append a "/" to the end of createProcedure for Oracle
-- CORE-1448 - Throw a more helpful error message and continue on if snakeyaml isn't in the classpath
-- CORE-1471 - Add support for Sybase IQ
-- CORE-1472 - Support multi-tenant spring applications
-
-
-
-
diff --git a/_posts/2013-10-11-new-liquibase-hibernate-extension-released.md b/_posts/2013-10-11-new-liquibase-hibernate-extension-released.md
deleted file mode 100644
index efef79db3..000000000
--- a/_posts/2013-10-11-new-liquibase-hibernate-extension-released.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: New Liquibase Hibernate Extension Released
----
-# New Liquibase Hibernate Extension Released
-
-After far too long, a new version of the Liquibase-Hibernate extension has been released!
-
-
-Downloads,
-documentation,
-and issue tracking
-is hosted at github.com/liquibase/liquibase-hibernate.
-The extension is also available through Maven with group org.liquibase.ext, artifacts liquibase-hibernate3 and liquibase-hibernate4.
-
-
-### Liquibase 3.0 Support
-
-
-If you've been stuck on Liquibase 2.0 because of the old hibernate integration, the
-wait is over. The extension requires Liquibase 3.0.6+, so make sure you are on the newest version of Liquibase.
-
-
-### Hibernate 4 Support
-
-
-There are two separate jar files available: liquibase-hibernate3.jar and liquibase-hibernate4.jar. Use the version that corresponds to your Hibernate version
-
-
-### EJB3 Configuration Support
-
-
-If you are using the EJB3-style persistence.xml file, you can now use a database url of "*hibernate:ejb3:yourPersistenceUnit*".
-
-
-### Spring Configuration Support
-
-
-If your Hibernate configuration is specified in Spring, you can now use a database
-of "*hibernate:spring:your/path/spring.xml?bean=sessionFactory*" to pull the Hibernate configuration from your spring context.
-
-
-### Programmatic Configuration Support
-
-
-You can now create your Hibernate configurations dynamically by implementing
-*liquibase.ext.hibernate.customfactory.CustomClassicConfigurationFactory* or
-*liquibase.ext.hibernate.customfactory.CustomEjb3ConfigurationFactory* and reference the
-classes in your database url. For example, "*hibernate:classic:com.example.YourFactory*" or "*hibernate:ejb3:com.example.YourFactory*"
-
-
-### Upgrade Notes:
-
-- The standard database url has changed from "hibernate:path/to/your/file.xml" to "hibernate:classic:path/to/your/file.xml"
-- Requires Liquibase 3.0.6+
-- Jar name has changed from liquibase-hibernate.jar to liquibase-hibernate3.jar (or liquibase-hibernate4.jar)
-
-
-
-
diff --git a/_posts/2013-10-15-group-of-liquibase-extensions-updated.md b/_posts/2013-10-15-group-of-liquibase-extensions-updated.md
deleted file mode 100644
index b653b34dd..000000000
--- a/_posts/2013-10-15-group-of-liquibase-extensions-updated.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Group of Liquibase Extensions Updated
----
-# Group of Liquibase Extensions Updated
-
-There has been a lot of activity the last couple weeks on the Liquibase extensions I manage and/or have source access to. There were a few running up against the Oct 15th jira-svn-shutdown deadline and also several that had not been updated to support Liquibase 3.0 yet.
-
-
-For all of the extensions, I have moved their source repository out of the shared liquibase.jira.com subversion repository and into their own repositories at https://github.com/liquibase. They all now have their own issue tracking, wiki, and releases tab in their Github projects, which is the pattern I will be using for all the Liquibase-managed extensions.
-
-
-I also released the new builds into Maven under the org.liquibase.ext group (some may still be propagating through the mirrors).
-
-
-### The recently updated extensions are
-
-
-**Oracle Database Support (https://github.com/liquibase/liquibase-oracle)**
-
-
-Improved support for Oracle database. Adds additional refactoring tags and snapshot support for Oracle-specific object types
-
-**Hana Database Support (https://github.com/liquibase/liquibase-hanadb)**
-
-Support for SAP's Hana Database
-
-
-**Teradata Database Support (https://github.com/liquibase/liquibase-teradata)**
-
-Adds support for Teradata database. *Still in beta because I am looking for Teradata users to test it*
-
-
-**No Change Log Update (https://github.com/liquibase/liquibase-nochangelogupdate)**
-
-
-Makes Liquibase run without updating the DATABASECHANGELOG table. Not what you normally want, but there are times it is handy
-
-
-**java.util.Logger Support (https://github.com/liquibase/liquibase-javalogger)**
-
-Log through java.util.Logger rather than STDERR
-
-**Sequence Table (https://github.com/liquibase/liquibase-sequencetable)**
-
-Support "sequence tables" like Hibernate can use for databases that do not support native schemas
-
-
-**Modify Column (https://github.com/liquibase/liquibase-modify-column)**
-
-Support for the deprecated `` change from Liquibase 1.x
-
-
-
-The main "Liquibase Extension Portal" is still at liquibase.org/extensions, the above extensions are simply the subset of extensions that I tend to manage. In the upcoming weeks, I will be working to improve the extension portal and the extension writing process in general (including better documentation)
diff --git a/_posts/2013-10-24-liquibase-3-0-7-release.md b/_posts/2013-10-24-liquibase-3-0-7-release.md
deleted file mode 100644
index bf4b7abed..000000000
--- a/_posts/2013-10-24-liquibase-3-0-7-release.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0.7 Release
----
-# Liquibase 3.0.7 Improves Memory Usage
-
-Lots of good bugfixes in 3.0.7, but major improvements are:
-
-- Significantly decreased memory usage, especially with large sql files
-- Improved checksum performance
-- Fixed SQLite support
-- Improvements to data type handling, especially in MS SqlServer
-
-
-### Discovered Checksum Issue:
-
-It was recently discovered that a change in the 3.0.5 release caused changeSets with `update` and `delete` changeSets with `where` clauses to compute a different checksum version than the 3.0.0-3.0.4 release. I decided to leave the 3.0.5 fix in because at this point, people would be affected by either leaving or reverting the change and keeping it in will preserve the bugfix. If you are upgrading from 2.x or 3.0.5+, this will not affect you. If you are upgrading from 3.0.0 through 3.0.4 and have no `` or `` changeSets, this will not affect you. If you do run into this, you simply have to null out the md5sum column in databasechangelog for the affected changesets. This can be done either through an "update databasechangelog set md5sum=null" call or a more targeted "update databasechangelog set md5sum=null where id='AFFECTED_ID' and author='AFFECTED AUTHOR'". There is also a "liquibase clearCheckSums" command that runs the update query.
-
-### Download
-
-Download Liquibase from http://liquibase.org/download or from the Maven repository as it winds its way through the mirror process. Visit the user forums if you have any questions.
-
-
-### All Closed Issues
-
-- CORE-1247 - (Sqlite) bad syntax in create table statements with single autoincrement primary key
-- CORE-1275 - LoadData insert statements do not escape column names containing an open paren
-- CORE-1312 - Error when creating changelog tables
-- CORE-1399 - IncludeAll Failing when running in WAR files
-- CORE-1440 - Invalid Reorg table statement gets generated on DB2
-- CORE-1504 - dbDoc should html-encode author names
-- CORE-1506 - updateSQL generates invalid SQL for oracle
-- CORE-1507 - dropAll fails with NullPointerException
-- CORE-1509 - Memory improvements for large sqlFile files
-- CORE-1510 - Maven plugin fails to configure parameters within property file with trailing spaces, error message misleading
-- CORE-1511 - modifyDataType truncates enum values
-- CORE-1512 - Insert with valueClobFile fails with unicode encoding.
-- CORE-1515 - Liquibase MSSQL: Snapshot incorrectly injecting size for some datatypes
-- CORE-1516 - Liquibase MSSQL: Snapshot recording incorrect size for VARBINARY
-- CORE-1517 - Liquibase MSSQL: Autoincrement property of decimal datatype not supported
-- CORE-1518 - Liquibase MSSQL: Incorrect datatypes captured in the snapshot
-- CORE-1520 - Liquibase Snapshot: Default datetime is wrong
-- CORE-1521 - When generateChangeLog is run, objects do not always come back in a consistent order
-- CORE-1522 - PreparedStatement.setCharacterStream() not supported by Postgres JDBC driver.
-- CORE-1524 - Ant diff command running diffChangeLog
-- CORE-1525 - Liquibase MSSQL: Snapshot not capturing alter statements that add default values
-- CORE-1526 - Unicode string escaping in MSSQL
-- CORE-1530 - Column called VERSION is quoted in PostgreSQL
-- CORE-1531 - includeAll with relativeToChangeLogFile fails under certain conditions
-- CORE-1532 - NPE in ChangedIndexChangeGenerator
-- CORE-1534 - Single quotes in liquibase.bat causing issues
-- CORE-1519 - Allow relative file paths for valueClobFile and valueBlobFile inserts/updates.
-- CORE-1533 - Performance improvements in dropAll
diff --git a/_posts/2013-10-28-liquibase-survey-2013.md b/_posts/2013-10-28-liquibase-survey-2013.md
deleted file mode 100644
index 1aa5df903..000000000
--- a/_posts/2013-10-28-liquibase-survey-2013.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Survey 2013
----
-# Liquibase Survey 2013
-
-One problem with running an open source project is that we don't really have "customers" to contact for feedback and product suggestions. I can definitely just add features that* *I** think make sense, but one thing I've learned is that people use Liquibase in amazing ways I would never have imagined.
-
-That is where the Liquibase survey comes in: it is your chance to provide feedback on how you use Liquibase and what is important to you so that I can better prioritize efforts over the next year.
-
-Your participation and time is greatly appreciated.
-
-#### -----> Liquibase Survey 2013 Form <-----
-
-
-If you know others that use Liquibase, please forward them the survey as well.
-
-Even better, if you know someone who is NOT using Liquibase, send them the survey as well.
-
-The more information I can gather the better picture I will have.
diff --git a/_posts/2013-11-13-liquibase-survey-ends-november-15th.md b/_posts/2013-11-13-liquibase-survey-ends-november-15th.md
deleted file mode 100644
index 743418d8b..000000000
--- a/_posts/2013-11-13-liquibase-survey-ends-november-15th.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Survey Ends November 15th
----
-# Liquibase Survey Ends November 15th
-
-If you haven't yet filled out the Liquibase 2013 Survey now is the time--it will be available only through the end of Friday, November 15th.
-
-
-There have been some great comments and feedback so far and thank you to everyone who has taken the time so far to submit a response.
-
-
-For those interested, I will post a summary of the results before the end of November.
-
-### —–> Liquibase Survey 2013 Form <—–
-
-
-
diff --git a/_posts/2013-11-14-experimental-amazon-redshift-support.md b/_posts/2013-11-14-experimental-amazon-redshift-support.md
deleted file mode 100644
index 428964fda..000000000
--- a/_posts/2013-11-14-experimental-amazon-redshift-support.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Experimental Amazon Redshift Support
----
-# Experimental Amazon Redshift Support
-
-A new Liquibase-Redshift extension is now available at https://github.com/liquibase/liquibase-redshift. If you are interested in trying out Liquibase with Amazon Redshift, give it a try and let me know how well it works.
-
-You can download the most recent builds from the "releases" tab.
diff --git a/_posts/2013-11-14-liquibase-hibernate-extension-3-1-released.md b/_posts/2013-11-14-liquibase-hibernate-extension-3-1-released.md
deleted file mode 100644
index b0b5f02fe..000000000
--- a/_posts/2013-11-14-liquibase-hibernate-extension-3-1-released.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase-Hibernate Extension 3.1 Released
----
-# Liquibase Hibernate Extension 3.1 Released
-
-The Liquibase hibernate extension has been updated for both hibernate 3 and hibernate 4.
-
-This release adds support for catching changes to sequences and unique constraints as well as a few bugs around data type handling.
-
-See https://github.com/liquibase/liquibase-hibernate for more information and to download the 3.1 release.
-
-
-*UPDATE:* A null pointer issue was found in the 3.1 release and fixed in a now available 3.2 release.
diff --git a/_posts/2013-12-12-liquibase-3-0-8-released.md b/_posts/2013-12-12-liquibase-3-0-8-released.md
deleted file mode 100644
index 4784d3edf..000000000
--- a/_posts/2013-12-12-liquibase-3-0-8-released.md
+++ /dev/null
@@ -1,104 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.0.8 Released
----
-# Liquibase 3.0.8 Released
-
-Liquibase 3.0.8 is officially released. It is purely a bugfix release that covers improvements to data type handing, performance improvements, and much more.
-
-### Download
-
-Download Liquibase from http://liquibase.org/download or from the Maven repository as it winds its way through the mirror process. Visit the user forums if you have any questions.
-
-### All Closed Issues
-
-
-- CORE-1224 - Enum column types are not appropriately represented in the change log created by generateChangeLog
-- CORE-1299 - modifyDataType does not auto reorg on DB2
-- CORE-1302 - MySQL syntax for autoincrement column with start value
-- CORE-1357 - Postgresql sequences create error in log files
-- CORE-1368 - Unable to recreate DB from generated change logs
-- CORE-1427 - Not generateChangeLog properly for INT2 type for Postgres
-- CORE-1430 - When I was in sybase database using liquibase create the index, reported "information_schema.constraints" not found error
-- CORE-1432 - Liquibase H2 InsertOrUpdateGeneratorH2 fails if primary key column name contains $ character
-- CORE-1446 - Liquibase changelog generation can add linefeed to defaultValueComputed if last column
-- CORE-1454 - Precondition negation does not seem to work
-- CORE-1455 - Value not taken into account when inserting data with YAML
-- CORE-1484 - very poor performance of dropAll on Oracle
-- CORE-1496 - Custom Change validation happening before being fully initialized
-- CORE-1531 - includeAll with relativeToChangeLogFile fails under certain conditions
-- CORE-1537 - Liquibase: diffChangeLog on DB2 performing out of order steps
-- CORE-1538 - diffChangeLog for DB2 injects invalid characters in xml
-- CORE-1540 - Call 'Reorg table' after modifyDataType on DB2
-- CORE-1541 - Column type="LONGVARCHAR" fails
-- CORE-1545 - Oracle wrong LONG datatype declaration
-- CORE-1547 - CLONE - H2 (and other) support for BLOB and CLOB is incorrect
-- CORE-1548 - Oracle Data Type: DATE - defaultValueComputed should be defaultValue
-- CORE-1549 - Oracle Data Type: INTERVAL YEAR TO MONTH - returned at "INTERNAL(2) YEAR"
-- CORE-1550 - Oracle Data Type: NCLOB - Receive SQL error when specifying NCLOB size
-- CORE-1551 - Oracle Data Type: NCHAR
-- CORE-1552 - Oracle Data Type: NVARCHAR2 - Column sizing is wrong
-- CORE-1553 - dropDefaultValue does not work on SQL Server
-- CORE-1554 - dbDoc for Informix IDS
-- CORE-1555 - Oracle UID reserved word not detected
-- CORE-1557 - Mysql: BLOB type changes to LONGBLOB
-- CORE-1559 - Columns defined as "serial" are created as "int" without autoincrement in Postgres
-- CORE-1562 - update throws Recoverable Exception
-- CORE-1564 - Broken links in dbDoc
-- CORE-1566 - DB2 Datatype - DBCLOB, GRAPHIC, VARGRAPHIC doubling datatype size
-- CORE-1567 - DB2 Datatype - defaultValueComputed being used instead of defaultValue for DBCLOB, TIME, TIMESTAMP, DATE
-- CORE-1568 - DB2 Datatype - REAL and XML should not have datatype sizes
-- CORE-1571 - updateDatabase can't find a changelog
-- CORE-1572 - Regression: diff generates full schema instead of changes when using liquibase-hibernate4
-- CORE-1580 - Mysql SET type not handled correctly
-- CORE-1581 - modifyDataType ignores additional info of newDataType
-- CORE-1582 - SQLServer datatype for TIMESTAMP
-- CORE-1583 - Wrong datatype with renameColumn
-- CORE-1584 - Unable do rollback not in transaction block
-- CORE-1586 - MySQL DataType - defaultValueComputed being injected into TIMESTAMP, VARBINARY, BINARY, YEAR
-- CORE-1587 - MySQL Datatype - VARBINARY vs LONGBLOB confusion
-- CORE-1588 - MySQL DataType - BIT size and default not captured on Snapshot
-- CORE-1589 - MySQL DataType - BLOB becomes LONGBLOB
-- CORE-1590 - MySQL DataType - DOUBLE sizing not persisted on snapshot
-- CORE-1591 - MySQL DataType - TIME not persisting seconds (getting hours and minutes..so I've got that going for me.)
-- CORE-1592 - MySQL DataType - TEXT converted to LONGTEXT
-- CORE-1594 - PostgreSQL 'bigserial' type is automatically converted to 'bigint'
-- CORE-1595 - Schema version incompatibility is logged as INFO instead of WARN
-- CORE-1596 - Liquibase 3.0.5 will not create tables in dbo schema in SQL Server
-- CORE-1597 - ORA-01000: maximum open cursors exceeded
-- CORE-1600 - "Collation" and "Lateral" are not escaped in Postgres (new reserved words in v9.3)
-- CORE-1602 - DatabaseException in changesets that include date fields with default values
-- CORE-1603 - MySQL Datatype - BIGINT, INT, MEDIUMINT, SMALLINT, TINYINT all "shaving" off sizes
-- CORE-1606 - MySQL - TEXT vs. LONGTEXT for diffChangeLog presents CLOB
-- CORE-1607 - MSSQL java.sql.Types.TIMESTAMP should map to DateTime
-- CORE-1610 - MSSQL - NTEXT type being snapshot with MSSQL driver default size parameter.
-- CORE-1611 - Avoid reverse DNS lookup with getLocalHost().getHostName();
-- CORE-1612 - YAML/JSON changelogs not picking up "value" attribute on column configs
-- CORE-1614 - mysql case insensitive affects databasechangelog creation
-- CORE-1615 - Failed to drop default value in MSSQL
-- CORE-1616 - SQLFileChange uses too many file descriptors
-- CORE-1619 - MSSQL: preconditions treat object names in a case-sensitive way
-- CORE-1622 - Ant not respecting diffTypes=data
-- CORE-1623 - MSSQL: precondition primaryKeyExists doesn't work
-- CORE-1625 - H2 Blob Type support is incorrect
-- CORE-1626 - createIndex does not work for function based indexes anymore
-- CORE-1627 - Option 'diffTypes' does not accept type 'indexes'
-- CORE-1632 - It's impossible to setup Logger's log level with system property 'liquibase.defaultlogger.level'
-- CORE-1636 - Case sensitivity issue with tableExists precondition
-- CORE-1640 - foreignKeyExists precondition always failing
-- CORE-1641 - Add column with foreign key throws NPE
-- CORE-1644 - ValidationFailedException after update to 3.0.7
-- CORE-1646 - Exception when comparing two schemas
-- CORE-1647 - Mysql enum default values not quoted
-- CORE-1648 - Mysql columns with colons and other special chars are not quoted
-- CORE-1664 - MSSQL. "DATE" type doesn't exist for MSSQL 2005 and 2000.
-- CORE-1382 - Allow to create DATABASECHANGELOG* tables in another schema
-- CORE-1546 - Schema-Support on Informix
-- CORE-1577 - Oracle tinyint, smallint, int being created as number(38,0)
-- CORE-1604 - Minor maven pom cleanups
-- CORE-1635 - Generated changelog missing unique constraints should be output before foreign keys
-
-
-
-
diff --git a/_posts/2014-01-09-liquibase-3-1-0-released.md b/_posts/2014-01-09-liquibase-3-1-0-released.md
deleted file mode 100644
index a06f7a113..000000000
--- a/_posts/2014-01-09-liquibase-3-1-0-released.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.1.0 Released
----
-# Liquibase 3.1.0 Released
-
-Liquibase 3.1.0 has been released. For most people 3.1 is a drop in replacement for 3.0.
-
-
-If you use `` with relative paths or are running against MaxDB, DB2 for iSeries, or InterSystems Cache make sure you read the upgrade guide.
-
-Besides bugfixes, 3.1 adds the following major features:
-
-### Offline Database Support!
-
-One of the most requested features is the ability to use Liquibase when you do not have direct access to the database. We have always had updateSql support, but it still required a database connection to know what has been ran and what type of database to generate SQL for.
-
-With the new "offline" support, you can now define a database connection URL like "*offline:mysql*" or "*offline:oracle?version=11.1*" when you run updateSql.
-
-In offline mode, the change history is tracked in a local csv file which can be controlled with the "changeLogFile" URL parameter. For example: *offline:mysql?changeLogFile:/home/db/changelog.csv*
-
-For more information, see the offline database documentation
-
-
-### Alternate Changelog History Tracking
-
-With 3.1, you can now create extensions that manage changelog history tracking differently than the standard "DATABASECHANGELOG" table. For example, https://github.com/liquibase/liquibase-filechangelog allows you to manage your changelog history using a local file rather than a table in the database.
-
-
-### New and Improved Change tags:
-
-- createProcedurenow supports referencing an external file containing the procedure definition with a new "path" attribute
-- createProcedure now supports a dbms attribute to target the database(s) the procedure is compatible with. This allows you to have a single changeSet with a procedure definition for each supported database
-- New dropProcedure change
-- addColumn supports new "beforeColumn", "afterColumn" and "position" attributes to control column ordering
-- sqlFile files support ${} parameters
-
-#### New and Improved Precondition tags:
-
-- `` now supports checking based on table and column definition. Not just constraint name
-- New `` precondition
-
-- New `` precondition
-
-#### Database Support Improvements
-
-- MySQL ENUM and SET type support improvements
-- MySQL support for date/time/timestamp size parameter
-- MySQL support for column remarks
-- MS SqlServer support for sequences (2012+)
-- Sybase general support improvements
-- DB2 general support improvements
-
-#### Extension/API Improvements
-
-- liquibase.changelog.visitor.ChangeExecListener implementations are notified of precondition and change-level interactions
-- SnapshotGenerator extensions can block incorrect functionality from other SnapshotGenerators
-- Extensions can define custom XSDs and namespaces
-
-#### Other Features and Improvements
-
-- Formatted SQL now supports a comma-separated list in "dbms" targeted changeSets
-- Maven support for futureRollbackSql command
-
-#### Links
-
-- Download 3.1.0
-- Full Jira Release Notes
-- User Forum
diff --git a/_posts/2014-01-16-liquibase-3-1-1-released.md b/_posts/2014-01-16-liquibase-3-1-1-released.md
deleted file mode 100644
index 84f53d73c..000000000
--- a/_posts/2014-01-16-liquibase-3-1-1-released.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.1.1 Released
----
-# Liquibase 3.1.1 Released
-
-Liquibase 3.1.1 has been released with a few bug fixes.
-The most important fixes reverts how `` checksums are computed so they are compatible with 3.0 and fix the new `` and `` preconditions.
-
-The newest version can be download from liquibase.org/download
-
-### Change Log
-
-- CORE-1704 - Checksum errors for changeSets with createProcedure in 3.1.0 vs 3.0.x
-- CORE-1707 - TableRowCountGenerator shouldn't pass tableName as catalogName
-- CORE-1710 - Oracle: NUMBER data type size specification is deployed with a precision specifier even though precision isn't specified in the change log
-- CORE-1711 - rowCount doesn't work if only the tableName is given
-- CORE-1713 - liquibase.precondition.core.ForeignKeyExistsPrecondition exception
-- CORE-1715 - 2 -> 3.1 migration, 3.1 errors if there are single quotes in comments
-- CORE-1709 - generateChangeLog returns tables created by Materialized Views as standard tables
-
-Complete Change Log
-
-
-
diff --git a/_posts/2014-02-17-liquibase-hibernate-extension-3-3-released.md b/_posts/2014-02-17-liquibase-hibernate-extension-3-3-released.md
deleted file mode 100644
index 3aa657966..000000000
--- a/_posts/2014-02-17-liquibase-hibernate-extension-3-3-released.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase-Hibernate Extension 3.3 Released
----
-# Liquibase Hibernate Extension 3.3 Released
-
-The Liquibase hibernate extension has been updated for both hibernate 3 and hibernate 4.
-
-Major changes include:
-
-- Support for Liquibase 3.1.1
-- Support for Hibernate 4.3+ *NOTE: Due to hibernate incompatibilities, Hibernate 4.0-4.2 requires the use of the liquibase-hibernate4.2 extension*
-- Support for compound primary keys
-- Improved support for detecting auto-increment columns
-
-
-See https://github.com/liquibase/liquibase-hibernate for more information and to download the 3.3 release.
-
-
-The new versions are also working their way through the maven mirror system
-
-
-
diff --git a/_posts/2014-03-10-liquibase-talk-at-percona-live.md b/_posts/2014-03-10-liquibase-talk-at-percona-live.md
deleted file mode 100644
index 683d22618..000000000
--- a/_posts/2014-03-10-liquibase-talk-at-percona-live.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase talk at Percona Live
----
-# Liquibase Talk at Percona Live
-
-I'll be giving a talk at Percona Live in Santa Clara on April 3rd titled "*Liquibase: Source Control For Your Schema*".
-
-It is a beginner-level course covering Liquibase basics plus some best practices. More information
-
-If you will be there, stop by and say hi. It's always great to hear from people using or considering using Liquibase. If you have not yet registered, use the promotional code "SeeMeSpeak" for a 10% discount.
diff --git a/_posts/2014-04-04-slides-from-percona-live-talk.md b/_posts/2014-04-04-slides-from-percona-live-talk.md
deleted file mode 100644
index 725e76bce..000000000
--- a/_posts/2014-04-04-slides-from-percona-live-talk.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Slides From Percona Live Talk
----
-# Slides from Percona Live Talk
-
-I posted the slides from my Percona Live talk at https://www.percona.com/live/mysql-conference-2014/sessions/liquibase-source-control-your-schema.
-
-I modified them from the actual talk slides to also include my speaking notes so they will be more helpful for those who were not able to make it to the talk or if you wish you took better notes.
-
-I'm hoping to post a recorded version of the talk in the next few weeks as well.
diff --git a/_posts/2014-06-02-liquibase-3-2-0-released.md b/_posts/2014-06-02-liquibase-3-2-0-released.md
deleted file mode 100644
index 70c55f053..000000000
--- a/_posts/2014-06-02-liquibase-3-2-0-released.md
+++ /dev/null
@@ -1,176 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.2.0 Released
----
-# Liquibase 3.2.0 Released
-
-Liquibase 3.2.0 has been released. As usual, it can be downloaded from the Liquibase download page and is available in the Maven repository as org.liquibase/liquibase-core.
-
-For most users, upgrading will be seamless but if you have written Liquibase extensions there have been some API changes. See http://www.liquibase.org/v3_2_upgrade.html for details.
-
-## Updated Extensions
-
-The following extensions have been updated to work with 3.2.0 and/or include bugfixes:
-
-- liquibase-hibernate
-- liquibase-oracle
-- liquibase-sqlfire
-- liquibase-modify-column
-- liquibase-db2i
-- liquibase-cache
-- liquibase-postgresql
-- liquibase-teradata
-- liquibase-nochangeloglock
-
-
-
-
-
-## Major new features and changes in 3.2.0 include:
-
-### And/Or/Not logic in context expressions
-
-
-
-Context attributes can now include complex expressions such as "qa or (production and master)". See the context documentation for more information
-
-
-### Improved JSON and YAML changelog parsing
-
-
-The changelog parsing logic has been greatly refactored to provide full feature parity between the XML, JSON, and YAML parsers.
-
-
-### New Command: Snapshot
-
-
-The command line interface supports a new "snapshot" command that will output a report of the objects Liquibase sees in a database. This is the model that would be fed into diff/diffChangeLog operations but doesn't perform any comparison logic, is simply reports on what it sees.
-
-
-### Liquibase SDK
-
-
-The Liquibase SDK will provide utilities and features not needed for standard Liquibase usage such as testing tools and extension writing help. The 3.2.0 release provides the first pieces of the SDK:
-
-
-- Offline Javadoc
-- A starter/example workspace
-- Ability to generate vagrant configurations for various databases
-- "Watch" command to provide a simple real-time view of the database schema
-
-
-
-For more information on the SDK, see the SDK Documentation.
-
-
-
-### Improved Performance
-
-
-Various improvements in memory usage and optimizations in database interactions
-
-
-### DatabaseChangeLog SQL available with Offline Database
-
-
-New "outputLiquibaseSql" flag allows inclusion of DatabaseChangeLog table create/insert statements with updateSql command
-
-
-### And Much More:
-
-
-- CORE-209 - Double Create Database Lock Table using updateSQL
-- CORE-421 - NPE in MySqlDatabaseSnapshot during diff operation when "enum" or "timestamp" column was removed from table
-- CORE-461 - Wrong datatypes for timestamps generated with generateChangeLog
-- CORE-871 - Unable to use changeSetPath in rollback tag to refer to another change log file
-- CORE-877 - Bug with column type "TIMESTAMP WITHOUT TIME ZONE"
-- CORE-976 - GenerateChangeLog with data: java heap space error
-- CORE-1097 - Liquibase adds a semicolon after a stored proc definition making the stored proc unusable
-- CORE-1108 - Oracle : Unable to create complex primary key for loadUpdateData
-- CORE-1284 - Memory leak in ExecutorService
-- CORE-1563 - dropAll does not delete Sequences on Derby
-- CORE-1572 - Regression: diff generates full schema instead of changes when using liquibase-hibernate4
-- CORE-1578 - changeset checksum calculates differently on linux and windows
-- CORE-1601 - updateSql generates SQL with unexpected linefeeds, breaks SQLPlus
-- CORE-1642 - Special character issue after upgrade
-- CORE-1643 - DB2: defaultSchemaName and changelogSchemaName are not respected
-- CORE-1650 - dropAll doesn't work on Informix
-- CORE-1668 - defaultSchemaName ignored on createTable in H2
-- CORE-1673 - Empty default value is not recorded for MySQL
-- CORE-1676 - Colons in changeSet IDs no longer supported
-- CORE-1688 - The 'valuum' extension seems not to be working under version 3.0.8 of liquibase
-- CORE-1701 - Oracle: snapshot of default date/time values come back as to_date functions
-- CORE-1714 - 2->3.1 migration error
-- CORE-1715 - 2 -> 3.1 migration, 3.1 errors if there are single quotes in comments
-- CORE-1718 - foreignKeyConstraintExists precondition fails with constraints on unique keys
-- CORE-1721 - HsqlDatabase.escapeObjectName(...) ignores QUOTE_ALL_OBJECTS
-- CORE-1727 - Drop default constraint syntax for DB2 not correct
-- CORE-1728 - Only sequence name is captured by snapshot process and used in generateChangeLog
-- CORE-1733 - Data in diffChangeLog coming through as one row per changeSet
-- CORE-1734 - updateSQL is not including content from sqlFile (at least not when ran from Linux)
-- CORE-1739 - Liquibase ignores Oracle varchar precision
-- CORE-1743 - Snapshot VARCHAR(MAX) correctly on sqlserver
-- CORE-1744 - Derby: UpdateSQL not including creating databasechangeloglock table if needed
-- CORE-1748 - Maven Plugin does not use outputDefaultCatalog property
-- CORE-1750 - liquibase-modify-column 3.0 broken with liquibase-core 3.1.1
-- CORE-1752 - Oracle XML Datatype snapshot containing size
-- CORE-1753 - HSQLDB 1.8 does not support catalogs
-- CORE-1754 - Default value functions on Oracle snapshoted as "defaultValue"
-- CORE-1755 - DefaultValueComputed is quoted for Char, Varchar, Clob, MediumInt and SmallInt types
-- CORE-1756 - Oracle indexes with functions not returned correctly in generateChangeLog
-- CORE-1765 - Failed to drop a VIEW pointing on not existing table from another schema
-- CORE-1767 - Oracle snapshot not capturing all indexes
-- CORE-1772 - Informix cannot drop constraints
-- CORE-1774 - Autocommit not restored on close in SpringLiquibase
-- CORE-1775 - Informix error when creating primary key
-- CORE-1779 - User Defined Types Come back with Unnecessary Size specifier in diff
-- CORE-1782 - dropALL fails when tables are referenced by other tables in another schema
-- CORE-1784 - GenerateChangeLog with objects in multiple schemas returns objects from multiple schemas and empty createTable statements
-- CORE-1788 - dropAll does not work in not default schemas using postgresql
-- CORE-1794 - Drop index failing for sybase
-- CORE-1797 - Autoincrement on type Serial8 fails
-- CORE-1798 - Invalid type syntax in Informix for Int(10) and SMALLINT(5) and FRACTION(3)
-- CORE-1799 - Attempted recreation of DATABASECHANGELOG in informix
-- CORE-1817 - Foreign Key Constraints Built on Unique Constraints are not captured in generateChangeLog
-- CORE-1818 - SQL Server "smalldatetime" converted to "datetime" on update
-- CORE-1824 - GUID Default values not quoted correctly in MSSQL
-- CORE-1828 - sqlFile should fail when file does not exists
-- CORE-1831 - CREATE/DROP INDEX issue: Sybase ASE 15.7.0
-- CORE-1834 - generateChangeLog creates DOUBLE(22) instead of double in MySql
-- CORE-1840 - Liquibase fails when run on a computer that can't connect to the internet
-- CORE-1843 - includeAll does not alphabetize classpath loaded files
-- CORE-1853 - Liquibase generates invalid SQL for 'character varying' type
-- CORE-1856 - Ability for Change classes to verify update and rollback succeeded
-- CORE-1859 - DataTypeFactory doesn't take database into account
-- CORE-1861 - MSSQLDatabase.isCaseSensitive() provides a wrong information
-- CORE-1878 - Maven plugin behaviour different than command line with the same parameters
-- CORE-1881 - Case sensitivity issue with tableExists precondition
-- CORE-1893 - type="DATETIME" in changelog is converted to TIMESTAMP in MySql
-- CORE-1899 - Non-existing referenced sql files doesn't report error
-- CORE-1901 - DropPrimaryKey - Fails in Postgres
-- CORE-1906 - Diff between objects in different named default schemas doesn't see them as the same object
-- CORE-1912 - Unit tests fail due to dependency on system time zone
-- CORE-1116 - Allow for both "AND" and "OR" specifications of which contexts to run
-- CORE-1422 - Support changeset comments in formatted SQL
-- CORE-1536 - Support specifying the referenceDefaultSchemaName for diff operations
-- CORE-1635 - Generated changelog missing unique constraints should be output before foreign keys
-- CORE-1682 - More machine-independent handling of filesystem-located resources
-- CORE-1695 - Better handling of Postgres timestamp with/without time zone
-- CORE-1706 - Excessive reading from databasechangelog table
-- CORE-1726 - Added offline parameter to generate insert databasechangelog statements
-- CORE-1758 - Add outputDefaultSchema flags to ant
-- CORE-1776 - System-independent checksums
-- CORE-1823 - Search for liquibase.properties in classpath in additional to local filesystem
-- CORE-1874 - Improve XML and other parsers for better extensiblity
-- CORE-1905 - Yaml parser supports .yml extension as well as .yaml
-- CORE-1686 - Add Support for Pivotal's SqlFire database to Liquibase
-- CORE-1742 - Standardized system for managing configuration options in core and extensions
-- CORE-1751 - More detailed API for returning changeSet statuses
-- CORE-1783 - Command line option: snapshot
-- CORE-1815 - Liquibase SDK command to easily watch database
-- CORE-1821 - Snapshot listener interface
-
-
-
-
diff --git a/_posts/2014-06-18-adding-liquibase-on-an-existing-project.md b/_posts/2014-06-18-adding-liquibase-on-an-existing-project.md
deleted file mode 100644
index be94a7e5c..000000000
--- a/_posts/2014-06-18-adding-liquibase-on-an-existing-project.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Adding Liquibase to an Existing project
----
-# Adding Liquibase to an Existing Project
-
-The Quick Start Guide works well for starting Liquibase on a new project because your empty changelog file matches your empty database. However, when you have an existing project with an existing database things are more complicated.
-
-Unfortunately, there is no simple "this is how you do it" answer because there is so much variations in projects, processes and requirements. Liquibase provides many tools to help the process, but it is up to you to decide the best way to combine them for your particular situation.
-
-When adding Liquibase to an existing project there are basically two approaches: "Make it look like you've always been using Liquibase" and "Just start using Liquibase"
-
-### Make it look like you've always been using Liquibase
-
-The goal of this approach is to have a changelog file that matches the current state of your database. You can run this changeLog against a blank database and the final result will be indistinguishable from your existing databases–as if you used Liquibase from the beginning. This approach is usually the best long term, but it can be more work up front.
-
-
-#### Create ChangeLog
-
-Creating the changelog to match your database can be done automatically using the generateChangeLog command or be done manually. For any database larger than a few tables, the generateChangeLog command is usually a good idea but make sure you go through the generated changeSets to ensure they are correct. Liquibase does not always detect more complex structures like stored procedures or details like if an index is not clustered. Also, ensure data types are as you expected them.
-
-
-#### Populate the DatabaseChangeLog table
-
-Once you have your changeLog, you need a way to ensure that the pre-Liquibase changeSets are only ran on new, empty databases. The easiest way to do this is generally to use the `changeLogSync` or `changeLogSyncSQL` command to execute (or generate) the SQL that marks the starting changeSets as already ran without actually executing them.
-
-As an alternative to the changeLogSync command, you can add contexts on the pre-Liquibase changeSets such as `` and when you run Liquibase on a new database you run with `liquibase --contexts=legacy update` and on an existing database you run with liquibase --contexts=non-legacy.
-Finally, you can add `` tags to the generated changeSets. For example, if you have a `` changeSet, you would add
-
-
-
-
-
-
-
-tag. Adding preconditions requires more changes to the changeLog file and introduces a performance penalty because Liquibase must check the database metadata for each changeSet the first run through, this approach is usually best used in isolated cases only.
-
-#### What is the current state?
-
-Often times a part of the reason to move to Liquibase is because your schemas have diverged over time, so an important question to answer is "If I'm making the changelog file match the current state, what *is* the current state?" Usually the best answer to that question is "the production database" but it can vary.
-
-How divergent your schemas are will also affect which of the above techniques you use to populate the DatabaseChangeLog table, and it will often times make sense to use multiple approaches. For example, you may want to generate your base changeLogs from the production database and use changeLogSyncSQL to be able to mark them ran on everything from production down. Then you can add your non-released changeSets to the changeLog file with a precondition checking if it has already ran. That will allow Liquibase to automatically figure out the correct state for all your databases from development through production.
-
-### We are going to use Liquibase starting…..NOW!
-
-Instead of building up a changeLog to match your existing database, you can instead just declare "from now on we are using Liquibase". The advantage to this is that it much easier to set up because it is just a mandate. Usually this works best going from one version to the next because your databases are all in a reasonably consistent state and you simply start tracking database changes in your next version using Liquibase. Because Liquibase only looks at the DatabaseChangeLog table to determine what needs to run, it doesn't care what else might be in your database and so it will leave all your existing tables alone and just run the new changeSets.
-
-The biggest disadvantage to this approach is that you cannot bootstrap an empty database with Liquibase alone. A work-around is to take a pre-Liquibase snapshot using your database backup tool and use that as your database seed. Any time you need to create a new database, you first load in the seed and then run Liquibase update.
-
-
-Depending on how much variation you have between your schemas, even with this approach you may need to rely on preconditions or a "mark changes ran" script in order to standardize and handle those variations.
-
-### People and Processes
-
-Finally, remember that starting to use Liquibase–especially on an existing project–isn't just about how you bootstrap your changeLog file. It is also a question of how you introduce Liquibase into your existing processes and culture.
-
-For many companies and projects, everyone realizes the problems that need fixing and are on board with the advantages of change. For others, however, there can be entrenched interests and strong resistance similar to any other process change. Liquibase provides many tools and approaches that can be used to ease it into an existing process such as SQL output, SQL formatted changelogs, diffChangeLog and more that can be combined in ways that works best for your group.
-
-
-If you know that introducing Liquibase is going to be complex, either from a technical or processes standpoint, it is usually best to introduce it slowly. Start with it on a new project as a trial run and once you have a good grasp of how it works and available options, apply it to other existing projects.
-
-
-NOTE: This post has been incorporated into the documentation at http://www.liquibase.org/documentation/existing_project.html
diff --git a/_posts/2014-07-18-liquibase-3-2-1-released.md b/_posts/2014-07-18-liquibase-3-2-1-released.md
deleted file mode 100644
index 7b08f9300..000000000
--- a/_posts/2014-07-18-liquibase-3-2-1-released.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.2.1 Released
----
-# Liquibase 3.2.1 Released
-
-Liquibase 3.2.1 has been released. As usual, it can be downloaded from the Liquibase download page and is available in the Maven repository as org.liquibase/liquibase-core.
-
-3.2.1 is purely a bugfix release. The only potential update issue could be a fix for incorrect checksums introduced in 3.2.0. If you used defaultValueNumeric, defaultValue or used createProcedure or sql tags you may have seen unexpectedly changed checksums with 3.2.0. With 3.2.1, those have been reverted back to the correct 3.1.x version. If you are updating from 3.1.x it will be a smoother update from 3.2.0. If you already updated to 3.2.1 and manually fixed your checksums in the databasechangelog table, they will need to be updated again.
-
-### Full change log:
-
-- CORE-1844 - bulkFetch of foreign keys on Oracle is very slow
-- CORE-1918 - Multiple comment blocks in changesets no longer works
-- CORE-1920 - SpringLiqubase includeAll is not including files
-- CORE-1922 - 3.2.0 Regression due to CORE-1721
-- CORE-1923 - Error raised: Unknown Reason when doing tagging via command line
-- CORE-1930 - Snapshot command returns no information on MSSQL
-- CORE-1933 - (3.0.8 -> 3.2.0) pom.xml: 2Mb of superfluous dependencies
-- CORE-1934 - file path in databasechangelog is absoulte since liquibase 3.2.0 when using includeAll inside a jar
-- CORE-1936 - NullPointerException while diffing database against hibernate.cfg.xml
-- CORE-1938 - defaultValueNumeric="0" or defaultValue="0" is translated to 0.0
-- CORE-1940 - Maximum Oracle Sequence fails to be parsed as a BigInteger
-- CORE-1944 - NullPointerException when tagging through Ant before applying changesets
-- CORE-1947 - Liquibase dependency to jetty-servlet/velocity should be `true`
-
-- CORE-1950 - Checksum validation failed after Liquibase upgrade (3.1.1 -> 3.2.0)
-- CORE-1957 - Using VARCHAR2 column type fails for Hsqldb running in oracle syntax mode
-- CORE-1960 - "Could not find implementation of liquibase.logging.Logger" starts appearing after migration from 3.1.1 to 3.2.0
-- CORE-1970 - NullPointerException on rollback with `` tag
-- CORE-1746 - Support `` parameters
-- CORE-1951 - Regression on 3.2.0 : --diffTypes=data generates Unknown Reason Exception
-
-**UPDATE:** There is still a couple checksum issues updating from 3.1.1 to 3.2.1. I'll get those fixed up in a 3.2.2 release today or tomorrow.
diff --git a/_posts/2014-07-24-liquibase-3-2-2-released.md b/_posts/2014-07-24-liquibase-3-2-2-released.md
deleted file mode 100644
index bf8b436b6..000000000
--- a/_posts/2014-07-24-liquibase-3-2-2-released.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.2.2 Released
----
-# Liquibase 3.2.2 Released
-
-Liquibase 3.2.2 has been released. It is a small bugfix release to fix a checksum regression from 3.1 -> 3.2 that was not fixed in 3.2.1.
-
-### Issues Resolved:
-
-- CORE-1938 - defaultValueNumeric="0" or defaultValue="0" is translated to 0.0
-- CORE-1950 - Checksum validation failed after Liquibase upgrade (3.1.1 -> 3.2.0)
-- CORE-1959 - generateChangeLog without changeLogFile - better error message
-
-
-
-As usual, it can be downloaded from the Liquibase download page and is available in the Maven repository as org.liquibase/liquibase-core.
-
-
-
-
diff --git a/_posts/2014-11-03-liquibase-3-3-0-released.md b/_posts/2014-11-03-liquibase-3-3-0-released.md
deleted file mode 100644
index 8391088f3..000000000
--- a/_posts/2014-11-03-liquibase-3-3-0-released.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.3.0 and 3.2.3 Released
----
-# Liquibase 3.3.0 and 3.2.3 Released
-
-Liquibase 3.2.3 and 3.3.0 have been released. As usual, they can be downloaded from the Liquibase download page and are available in the Maven repository as org.liquibase/liquibase-core.
-
-Both 3.2.3 and 3.3.0 should be drop-in replacements for 3.2.2. A new batch of Liquibase extensions will be released over the next few days.
-
-### New "label" attribute on changeSet
-
-Labels are general purpose way to categorize changeSets like contexts, but working in the opposite way. Instead of defining a set of contexts at runtime and then a match expression in the changeSet, you define a set of labels in the context and a match expression at runtime.
-
-The most common time you would use labels instead of contexts is when the person doing the liquibase update has the knowledge of the types of changeSets to run, not the person writing the changeSet.
-
-Labels can also be applied to modifySql
-
-### New change log commands and attributes
-
-- New "empty" tag for explicitly marking a changeSet as unused
-- New "output" tag for outputting a message during Liquibase update.
-- New relativeToChangeLogFile attribute for loadData and loadUpdateDate
-- New fullDefinition=true\|false attribute on createView to support defining an entire view definition (including "column" names)
-
-### Support for clustered/nonclustered indexes and primary keys
-
-A new "clustered='true\|false'" attribute is now avaiable on createIndex and createPrimaryKey to control whether they should be created as clustered or not.
-
-### And More
-
-- Saving of "remarks" in MySQL and MSSQL
-- Improved data type handling
-- Performance improvements
-- Official RPM and DEB packages built with release
-- Major refactoring and updating of Ant integration
-- Full release notes below
-
-### 3.2.3 Change Log
-
-3.2.3 is a patch release with smaller bug fixes. Even if not explicitly listed in the changelogs below, anything in 3.2.3 will be in 3.3.0.
-
-- CORE-1919 - SpringLiquibase fails when dropFirst is true
-- CORE-1987 - "mvn liquibase:diff" does not find any differences between databases
-- CORE-1988 - Reported size for Oracle NVARCHAR2 columns is wrong
-- CORE-1989 - Cannot set objectQuotingStrategy on root databaseChangeLog node
-- CORE-2002 - AbstractResourceAccessor generates path in a unpredictable way
-- CORE-2003 - Could not find implementation of liquibase.logging.Logger
-- CORE-2042 - If liquibase.jar is nested in another jar/war/ear, it fails to start with a "cannot find implementation of liquibase.logging.Logger" error
-- CORE-2058 - Load/Update tags should use "is null" not "= null" for null comparisons
-- CORE-2070 - dropAllForeignKeyConstraints does not work on Firebird databases
-- CORE-2075 - generateChangelog generates bad definition for TIME type
-- CORE-2080 - Liquibase "empty" change not present in XSD version 3.2
-- CORE-2065 - Use DOUBLE PRECISION for DOUBLE with Firebird
-- CORE-54 - Support System Properties in Maven Plugin
-
-
-### 3.3.0 Change Log
-
-- CORE-16 - Support for "nonclustered" primary keys in mssql
-- CORE-54 - Support System Properties in Maven Plugin
-- CORE-1528 - Installer for Liquibase
-- CORE-1598 - support for rename sequence
-- CORE-1914 - New Change function: output
-- CORE-1942 - Support for changeSet "labels"
-- CORE-549 - relativeToChangelogFile for loadData, loadUpdateData, sqlFile
-- CORE-1438 - createView should support having the entire view definition in the change body
-- CORE-1502 - CLONE - UpdateSQL needs to append a "/" to the end of createProcedure for Oracle
-- CORE-1654 - logicalFilePath support in formatted sql
-- CORE-1660 - "remarks" attribute is ignored in MSSQL
-- CORE-1932 - support for encrypted passwords / custom properties
-- CORE-1946 - Have a rpm package for liquibase (built with maven)
-- CORE-1963 - Ability to define full CREATE VIEW statement in `` change.
-- CORE-1990 - Preserve inline comments in view snapshots in mssql
-- CORE-2060 - Support liquibase.properties files with unknown properties
-- CORE-2061 - Improvements to Informix support
-- CORE-2062 - Add onlyUpdate flag to loadUpdateData
-- CORE-2064 - Use ignoreClassPathPrefix for rollback as well
-- CORE-2065 - Use DOUBLE PRECISION for DOUBLE with Firebird
-- CORE-2066 - Support for --outputFile in command line
-- CORE-2067 - Refactor Ant Task codebase
-- CORE-2068 - New liquibase.hostDescription property for additional details in the DATABASECHANGELOGLOCK table
-- CORE-2069 - Use prepared statement in `` change whenever a clob type is used
-- CORE-2072 - Do not include Oracle internal tables in snapshot/diff
-- CORE-870 - Postgres, in an ALTER TABLE ALTER COLUMN statement, sometimes needs USING clause
-- CORE-945 - Oracle : Temporary tables are created as regular tables
-- CORE-1463 - Views not generated correctly with generateChangelog
-- CORE-1556 - remarks attribute ignored for mysql
-- CORE-1723 - unable to update on DB2/400, version V6R1, on jt400-6.7.jar
-- CORE-1745 - afterColumn not working in MySQL
-- CORE-1774 - Autocommit not restored on close in SpringLiquibase
-- CORE-1882 - NullPointerException when MySQL foreign key points to an invalid table
-- CORE-1919 - SpringLiquibase fails when dropFirst is true
-- CORE-1922 - Sequence is not a reserved object name in HSQLDB
-- CORE-1925 - liquibase scripts can not represent clustered indexes
-- CORE-1937 - Oracle Float and VARCHAR precisions in changelog generated by generateChangeLog are incorrect
-- CORE-1952 - liquibase loadData does not properly load numeric field in boolean always as false
-- CORE-1956 - Double and float converted to FLOAT8(*, 17) and FLOAT4(*, 8) in PostgreSQL
-- CORE-1958 - Column type of "TIMESTAMP(6)" under MySql converted to TIMESTAMP dropping fractional seconds
-- CORE-1974 - dbchangelog-3.1.xsd missing ``
-- CORE-1977 - CreateSequence with cacheSize=0 failing on Oracle
-- CORE-1979 - MSSQL should not include parameters in SYSNAME data types
-- CORE-1981 - Parameters set in included file are no longer set in 3.2.0
-- CORE-1982 - Snapshot outputs defautlValueDate as defaultValueComputed on MSSQL for dates not in ISO format with a T in the middle
-- CORE-1986 - includeAll from changeLogs within a jar is not working
-- CORE-1988 - Reported size for Oracle NVARCHAR2 columns is wrong
-- CORE-1993 - Drop table with cascade is not supported by Sybase
-- CORE-1996 - addNotNullConstraint on h2 database has unexpected side effects
-- CORE-1997 - Bit changelog default value of 1 executed as 0
-- CORE-2002 - AbstractResourceAccessor generates path in a unpredictable way
-- CORE-2010 - Oracle data type SDO_GEOMETRY snapshotted as SDO_GEOMETRY(1)
-- CORE-2014 - applyToRollback property ignored when rollback changes are specified
-- CORE-2015 - DiffChangeLog writes to the wrong point in the file on windows if file uses \n not \r\n
-- CORE-2020 - Oracle default value current_timestamp converted to systimestamp
-- CORE-2021 - Column remarks not snapshotted in mssql
-- CORE-2026 - Oracle columns of type ANYDATA are snapshotted with a size
-- CORE-2028 - generateChangeLog on SQL Anywhere 11.0.1 throws DatabaseException Driver Not Capable
-- CORE-2032 - Snapshot incorrectly including clob/blob sizes on diff
-- CORE-2051 - Not quoting VIEW params with spaces when snapshotting
-- CORE-2054 - Add new "computed" column attribute to differentiate between an actual column name and a function as a column
-- CORE-2063 - Fix for H2 autoincrement "start with" and "increment by" syntax
-- CORE-2070 - dropAllForeignKeyConstraints does not work on Firebird databases
-- CORE-2075 - generateChangelog generates bad definition for TIME type
-- CORE-2080 - Liquibase "empty" change not present in XSD version 3.2
-- CORE-2081 - PrimaryKeyExists precondition without tableName is broken
-- CORE-2082 - Column snapshot on PostgreSQL does not include precision information for numeric data type
-- CORE-2087 - Executing against Oracle doesn't respect liquibaseSchemaName or liquibaseCatalogName
-- CORE-2088 - outputDefaultSchema and outputDefaultCatalog command line parameters not respected
-- CORE-2093 - Error: Property 'relativeToChangelogFile' not found on object type liquibase.change.core.LoadDataChange
-- CORE-2094 - Liquibase.dropAll() should reset the lock service
-- CORE-2095 - Invalid generated changeset for mysql bit with defaultValue 0
-
-
-
-
diff --git a/_posts/2014-11-18-contexts-vs-labels.md b/_posts/2014-11-18-contexts-vs-labels.md
deleted file mode 100644
index 0f36b7558..000000000
--- a/_posts/2014-11-18-contexts-vs-labels.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Contexts vs. Labels
----
-# Understanding Contexts vs. Labels
-
-A new feature with Liquibase 3.3 is "labels". Labels are similar to contexts in that both allow you to chose a subset of changeSets to execute at runtime. Labels are also similar to contexts in that both are purposely vague terms because they are fairly generic features can enable many different use cases. Where they differ is in who has the power to specify complex logic: the changeSet author or the deployment manager.
-
-### Contexts
-
-Liquibase contexts have been available for quite a while, and they started out primarily as a way of "tagging" changeSets so they can be chosen at runtime.
-One common use is to mark changeSets that insert test data as context="test" so that in your development and QA environments you you can run liquibase
-with `--contexts=test` to get the test data and in production you run with `--contexts=prod` to not have test data. Contexts are also helpful for marking
-changeSets based on feature sets to include (context="shoppingCart") or bundle (context="pro") or even customer (context="acme_inc"). For complex cases,
-multiple contexts can be applied to a changeSet such as context="acme_inc, pro" and multiple contexs can be chosen at runtime such as `--contexts=free,qa`.
-
-With Liquibase 3.2, support was added to for context expressions in changeSets. Now, when you are defining your changeSet you can specify complex logic
-such as context="!test" or context="qa or (acme_inc and dev)". The context logic can only be specified in your changeSet definition, however. When running
-Liquibase, you can still specify multiple contexts, but you are just listing out all the contexts that apply to the current Liquibase run.
-
-### Labels
-
-Labels were added in Liquibase 3.3 to work like contexts, but "backwards" in who can specify logical expressions. In your changeSet you can only specify a
-simple list of "labels" that apply to the changeSet but at runtime you can write a complex expression to chose the labels you want to execute. This allows
-you to specify a changeSet with labels="qa, acme_inc" and then at runtime use expressions such as `--labels="!acme_inc"` or `--labels="pro or (free and beta)"`.
-
-### Which is right for you?
-
-Whether you should use contexts or labels comes down to whether the changeSet writer or the Liquibase executor best understands and/or needs the most control over which changeSets to execute.
-
-- If the changeSet author needs to be able to specify complex logic based on the kind of environment that Liquibase will run in, use contexts.
-- If the person executing Liquibase needs to specify complex logic to chose changeSets to run, use labels.
-- If you do not use complex expressions, there is no functional difference between them.
-
-Remember: you can use both.
-
-### Example Use Cases
-
-Contexts work best when you can simply enumerate/describe features of the runtime environment:
-
-- Free vs Pro versions
-- QA vs. Dev. vs. Prod environments
-- Customer A vs. Customer B
-
-Labels work best when you can simply enumerate/describe what a changeSet is for, but the deployment time environment is complex to describe. An example of when
-labels would work well is when you can describe changeSets as for a particular feature or version such as "1.0" and/or "shopping_cart" but the decision on which
-features and/or versions needs to run is complex and chosen at deployment time. Labels in this case would allow you to run with `--labels="1.0 or (1.1 and shopping_cart)"`
-to deploy the 1.0 changeSets and only the 1.1. features related to the shopping cart to one database and `--labels="1.0 or (1.1 and !shopping_cart)"` to another database.
-
-When in doubt, I usually go with contexts because that will simplify deployment configuration (to minimize release-day problems) while giving changeSet authors the
-option to handle complex logic if needed.
diff --git a/_posts/2015-01-08-liquibase-3-3-2-released.md b/_posts/2015-01-08-liquibase-3-3-2-released.md
deleted file mode 100644
index e12967b9f..000000000
--- a/_posts/2015-01-08-liquibase-3-3-2-released.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.3.2 Released
----
-# Liquibase 3.3.2 Released
-
-Liquibase 3.3.2 is officially released. It is primarily a bugfix release, but has one major new feature: object diffChangeLog/generateChangeLog object filtering.
-
-### includeObjects/excludeObjects logic
-
-You can now set an includeObjects or excludeObjects paramter on the command line or Ant. For maven, the parameteres are diffExcludeObjects and diffIncludeObjects. The format for these parameters are:
-
-- An object name (actually a regexp) will match any object whose name matches the regexp.
-- A type:name syntax that matches the regexp name for objects of the given type
-- If you want multiple expressions, comma separate them
-- The type:name logic will be applied to the tables containing columns, indexes, etc.
-
-NOTE: name comparison is case sensitive. If you want insensitive logic, use the `(?i)` regexp flag.
-
-Example Filters:
-
-- "table_name" will match a table called "table_name" but not "other_table" or "TABLE_NAME"
-- "(i?)table_name" will match a table called "table_name" and "TABLE_NAME"
-- "table_name" will match all columns in the table table_name
-- "table:table_name" will match a table called table_name but not a column named table_name
-- "table:table_name, column:\*._lock" will match a table called table_name and all columns that end with "_lock"
-
-### Full 3.3.2 Change Log:
-
-- CORE-875 - Ignore tables for diffs and generateChangelog
-- CORE-1877 - SQLOutput prints endDelimiter regexes
-- CORE-2114 - AddAutoIncrement on Postgres does not work when changes are applied on a specific schema
-- CORE-2141 - handling dependencies and WAR as classpath
-- CORE-2166 - SpringLiquibase: includeAll within jar causes SetupException
-- CORE-2172 - dropPrimaryKey without constraint name on sql server doesn't honour schema information
-- CORE-2174 - Bad exception handling in OracleDatabase.setConnection
-- CORE-2180 - NPE with bad name
-- CORE-2182 - ClassLoader leak due to shutdown hooks
-
-Since the 3.3.0 announcement, **3.3.1 was also released in December as a bugfix release** with the following changes:
-
-- CORE-1920 - SpringLiqubase includeAll is not including files
-- CORE-2009 - ClassCastException when executing a custom task change (AntClassLoader problem)
-- CORE-2097 - "mvn liquibase:futureRollbackSQL" asks for tag, count or date
-- CORE-2099 - SQLAnywhere support (Driver not capable)
-- CORE-2103 - changelogSchemaName/changelogCatalogName configuration options will not work on Oracle DB
-- CORE-2104 - ConcurrentModificationException iterating over System.getProperties().entrySet()
-- CORE-2105 - Maven profile performing dropAll and update on Oracle failing with an error on populated database.
-- CORE-2107 - LOWER() keyword fails on Postgres createIndex task
-- CORE-2108 - dropAll command trying to drop column on table that has already been dropped
-- CORE-2116 - Could not find implementation of liquibase.logging.Logger
-- CORE-2118 - Change default diffChangeLog/generateChangeLog objectQuotingStrategy back to LEGACY
-- CORE-2119 - Bad finally block in SpringLiquibase.afterPropertiesSet()
-- CORE-2120 - LoadUpdateData with value=NUMERIC quoting values
-- CORE-2121 - DB2: DiffChangeLog/GenerateChangeLog/DropAll sees alias column and tries to drop/add them
-- CORE-2127 - updateSQL creates duplicate DATABASECHANGELOGLOCK tables
-- CORE-2130 - setFetchSize to a negative value breaks Oracle JDBC Driver
-- CORE-2134 - ExecuteCommand won't run with no os attribute.
-- CORE-2136 - Mysql must quote PARTITION as a keyword
-- CORE-2137 - Special characters ( ) copied during generateChangelog on DB2/400
-- CORE-2139 - H2Database.supportsDropTableCascadeConstraints() returns false
-- CORE-2142 - generateChangeLog not including all columns in a table
-- CORE-2146 - snakeyaml is pulled in as transitive dependency for using projects
-- CORE-2149 - Liquibase command line fails
-- CORE-2150 - On the 3.3.0-SNAPSHOT, liquibase --version returns 3.2.0
-- CORE-2153 - Liquibase 3.2.1 is no longer compatible with Oracle 9
-- CORE-2155 - diffTypes=data fails with java.sql.SQLException: Attribute value not valid (dataOutputDirectory attribute causes build to fail)
-- CORE-2156 - Resource loader can't load changelog file
-- CORE-2157 - SQLException if there are single quotes in ChangeSet
-- CORE-2159 - Datetime2 no longer used for MSSQL
-- CORE-2161 - includeAll relativeToChangelogFile="true" doesn't work
-- CORE-2164 - SpringLiquibase: includeAll within jar causes NullPointerException
-- CORE-2179 - Creating functional indexes
-- CORE-2115 - Really slow when using fat jars
-- CORE-2125 - Make DatabaseChangeLog#include(String, boolean, ResourceAccessor) public
-- CORE-2148 - Build failure on jdk-1.8
-- CORE-2152 - Change logs in json format not processed by liquibase - parsing errors
-
-### Updated Extensions
-
-The following extensions have also been recently updated with bugfixes, new features and support for Liquibase 3.3.x
-
-- Liquibase-Hibernate 3.5
-- Liquibase-Oracle 3.2
-- Liquibase-Teradata 3.1
-- Liquibase-Redshift 1.0
-
-### Download
-
-As always, Liquibase can be downloaded from the Liquibase download page and is available in the Maven repository as org.liquibase/liquibase-core. The extensions can be downloaded from their corresponding github repository "Release" pages.
diff --git a/_posts/2015-04-29-liquibase-3-3-3-released.md b/_posts/2015-04-29-liquibase-3-3-3-released.md
deleted file mode 100644
index cc63b14f7..000000000
--- a/_posts/2015-04-29-liquibase-3-3-3-released.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.3.3 Released
----
-# Liquibase 3.3.3 Released
-
-Liquibase 3.3.3 is primarily a bugfix release
-
-As always, Liquibase can be downloaded from the Liquibase download page and is available in the Maven repository as org.liquibase/liquibase-core.
-
-### Fixed Issues:
-
-- CORE-1768 - Oracle dropAll fails on spatial tables and sequences
-- CORE-1840 - Liquibase fails when run on a computer that can't connect to the internet
-- CORE-1857 - Wrong column size detection on varchar2 fields with char as datatype
-- CORE-1866 - Filtering changelog list by includeAll tag is not working
-- CORE-1943 - Handle Error: InetAddress.getLocalHost().getHostName() UnknownHostException results in NoClassDefFoundError
-- CORE-1958 - Column type of "TIMESTAMP(6)" under MySql converted to TIMESTAMP dropping fractional seconds
-- CORE-1967 - includeAll uses full file path for sql changelogs
-- CORE-2023 - Problem using includeAll with SpringLiquibase
-- CORE-2126 - Postgres 9.3 - Drop table With Cascade - Not Supported
-- CORE-2156 - Resource loader can't load changelog file
-- CORE-2186 - AbstractResourceAccessor#convertToPath(String, String) fails for processing includeAll from Classpath
-- CORE-2192 - NoSuchMethodException when generating offline Oracle migration script
-- CORE-2199 - Liquibase adds a semicolon after a stored proc definition making the stored proc unusable
-- CORE-2202 - liquibase.should.run inverted boolean
-- CORE-2204 - valueNumeric not being set when using prepared statements
-- CORE-2206 - diffChangeLog with JPA-annotated entities causes ConcurrentModificationException
-- CORE-2208 - Typo in message
-- CORE-2210 - java.lang.NullPointerException when file is empty
-- CORE-2214 - When inserting string value starting and ending with apostrophes (quotes) the value is not quoted in the generated SQL
-- CORE-2218 - Regression on modifyDataType : VARCHAR2 was supported on 3.2...and fails on 3.3
-- CORE-2239 - Remarks attribute in renameColumn causes parse error
-- CORE-2240 - setDropFirst(true) still broken on empty database
-- CORE-2262 - 3.3.2 ant task dies on NPE in ChangeLogParameters
-- CORE-2263 - Index Snapshot - doesn't include upper cased name indexes when db is NOT case sensitive
-- CORE-2274 - Ant Upade Task does not consider changeLogFile correctly if it is contained in a JAR
-- CORE-2279 - Rollback fails in MS SQL 2008 using liquibase 3.3.2
-- CORE-2284 - Creating a DatabaseChangeLog() results in NPE
-- CORE-2290 - Liquibase gives different results from Ant and the command line
-- CORE-2301 - Regression from 3.2.3 in mssql 2000 unsupported usage of varchar(max) and sys.extenden_properties
-- CORE-2304 - Autoincrement on type INT4 fails
-- CORE-2310 - IncludeAll Fails with Unknown Reason Error
-- CORE-2315 - NPE in CommandlineResourceAccessor
-- CORE-2325 - Liquibase - New versions break DB create
-- CORE-2329 - Escaped reserved keywords in HSQL are stored in lower case instead of upper case.
-- CORE-2330 - includeAll uses full file path with includeAll
-- CORE-2261 - UpdateSQL needs to append a "/" to the end of createProcedure for Oracle
-- CORE-2287 - Improve support for Groovy-based tests in Eclipse
-- CORE-2296 - Upgrade Groovy and Spock to maintained versions
-- CORE-2318 - Add support for converting BigDecimal objects to a SQL string via DataTypeFactory
-
-
-
-
diff --git a/_posts/2015-05-04-liquibase-and-datical.md b/_posts/2015-05-04-liquibase-and-datical.md
deleted file mode 100644
index 16a8f84e1..000000000
--- a/_posts/2015-05-04-liquibase-and-datical.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase and Datical
----
-# Liquibase and Datical
-
-For those of you who don't know, I've been working for Datical for the last year and a half as "Benevolent Dictator for Life." I often joke that I feel like I'm retired because after years of working on Liquibase as a hobby on nights and weekends I'm now spending my days working on my "hobby".
-
-The rest of the Datical team works on Datical DB which uses Liquibase. Datical DB wraps additional functionality around Liquibase such as:
-
-- Database specific objects such as Oracle Packages & SQL Server Functions
-- Forecast to simulate deployments
-- HTML reporting
-- Out-of-the-box integrations with Jenkins, IBM UrbanCode, CA Release Automation, and others
-- Rules Engine (using Drools) to help you control specific objects in your deployments.
-
-I've always considered the scope of Liquibase to be "git for your database"–flexible but with a single, vendor neutral purpose that is part of an overall application deployment process. Datical DB builds out the rest of toolset for those who need it.
-
-To help highlight and differentiate Liquibase and Datical, I've made a few updates to liquibase.org including a feature comparison on the download page and a more descriptive "Enterprise Version" menu link. Liquibase continues to be a separate product from Datical and will always remain open source. The changes are simply to point people to Datical DB if they are interested without getting in the way of those who simply use Liquibase.
diff --git a/_posts/2015-05-27-liquibase-3-3-4-released.md b/_posts/2015-05-27-liquibase-3-3-4-released.md
deleted file mode 100644
index 10de9a1b4..000000000
--- a/_posts/2015-05-27-liquibase-3-3-4-released.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.3.4 Released
----
-# Liquibase 3.3.4 Released
-
-Bugfix release Liquibase 3.3.4 is now available from liquibase.org/download and through the Maven repositories.
-
-The most notable fix was to make the Maven plugin "liquibase.should.run" flag default back to true like it should have vs. "false" in 3.3.3.
-
-### Full changelog:
-
-- CORE-2360 - Maven - Skip is active by default
-- CORE-2199 - Liquibase adds a semicolon after a stored proc definition making the stored proc unusable
-- CORE-2344 - Unknown host exception on OS RHEL 6.5
-- CORE-2346 - IncludeAll does not work when runing liquibase from inside a jar
-- CORE-2357 - alterSequence does not work as expected when you need to change the cache size
-- CORE-2366 - Derby Network server works with command line but not with maven "Liquibase skipped due to maven configuration"
-- CORE-2368 - No SQL outputted for `` change
-
-
-
-
diff --git a/_posts/2015-05-28-liquibase-3-3-5-released.md b/_posts/2015-05-28-liquibase-3-3-5-released.md
deleted file mode 100644
index a83e69081..000000000
--- a/_posts/2015-05-28-liquibase-3-3-5-released.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.3.5 Released
----
-# Liquibase 3.3.5 Released
-
-Yes, I know 3.3.4 just came out yesterday, but there was a configuration issue that affected dependencies in Maven.
-
-3.3.5 resolves this with no other changes.
diff --git a/_posts/2015-06-09-trimming-liquibase-changelogs.md b/_posts/2015-06-09-trimming-liquibase-changelogs.md
deleted file mode 100644
index 67a0501fb..000000000
--- a/_posts/2015-06-09-trimming-liquibase-changelogs.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Trimming Liquibase ChangeLogs
----
-# Trimming Liquibase ChangeLogs
-
-For people who have used Liquibase for a long time, a common question they have is how to clear out a changelog file that has gotten unwieldy.
-
-
-The standard process for using Liquibase is to append individual change sets to your changelog file for each database change you need to make. Over time those changes can build up to thousands of entries, many of which are now redundant (create a table and later drop it) or inefficient (create a table, then add columns individually vs. just creating the table with all the columns). What is the best way to simplify all that cruft that has built up?
-
-My first response is always "Do you really need to simplify it?" You built up that changelog over a long period of time and you have ran it and tested it countless times. Once you start messing with the changelog file you are introducing risk which has a cost of its own. Does whatever performance or file size concerns you have really outweigh the risk of messing with a script that you know works?
-
-If it is worth the risk, why is it work the risk? Sometimes the problem is that your changelog file has just gotten so large that your editor chokes on it, or you get too many merge conflicts. The best way to handle this is to simply break up your changelog file into multiple files. Instead of having a single changelog.xml file with everything in it, create a master.changelog.xml file which uses the `` tag to reference other changelog files.
-
-{% highlight xml %}
-
-
-
-
-
-
-{% endhighlight %}
-
-When you run `liquibase update` against the master.changelog.xml file, changeSets in com/example/news/news.changelog.xml will run and then the changeSets in com/example/directory/directory.changelog.xml will run. You can break up changeSets in whatever manner works best for you. Some break them up by feature, some break them up by release. Find what works best for you.
-
-
-Other times, the problem is that `liquibase update` is taking too long. Liquibase tries to be as efficient as possible when comparing the contents of the DATBASECHANGELOG table with the current changelog file and even if there are thousands of already ran changeSets, an "update" command should take just seconds to run. If you are finding that update is taking longer than it should, watch the Liquibase log to determine why. Perhaps there is an old runAlways="true" changeSet that no longer needs to run or there are preconditions which are no longer needed. Running Liquibase with –logLevel=INFO or even –logLevel=DEBUG can give additional output which can help you determine which changeSets are slow. Once you know what is slowing down your update, try to alter just those changeSets rather than throwing out the whole changelog and starting from scratch. You will still want to retest your changelog in-depth, but it is a far less risky change.
-
-
-For other people, they find that `liquibase update` works well for incremental updates, but creating a database from scratch takes far too long. Again I would ask "is that really a problem?" Are you re-creating databases often enough that the risk of a change to the creation script makes sense? If you are, your first step should be to look for problem changeSets as described above. Databases are fast, especially when they are empty. Even if you create a table only to drop it again that is usually just a few milliseconds of overhead and not worth optimizing. The biggest performance bottlenecks in creating a database are usually indexes, so start with them. If you are creating and updating indexes frequently in your creation process, you may be able to combine those changeSets into something more efficient.
-
-
-When you need to surgically alter your existing changeSets, remember how Liquibase works: each changeSet has an "id", an "author", and a file path which together uniquely identifies it. If the DATABASECHANGELOG table has an entry for that changeSet it will not run it. If it has an entry, it throws an error if the checksum for the changeSet in the file doesn't match what was stored on the last run.
-
-
-How you modify your existing changeSets will also depend on your environment and where in the changelog the problem changeSets are. If you are modifying changeSets that have been applied to all of your environments and are now only used on fresh database builds you can treat them differently than if they have been applied to some databases but not yet to others.
-
-
-To merge or modify existing changeSets you will be doing a combination of editing existing changeSets, removing old changeSets, and creating new ones.
-
-
-Removing unneeded changeSets is easy because Liquibase doesn't care about DATABASECHANGELOG rows with no corresponding changeSets. Just delete out of date changeSets and you are done. For example, if you have a changeSet that creates the table "cart" and then another that drops it, just remove both changeSets from the file. You must make sure, however, that there are no changeSets between the create and the delete that make use of that table or they will fail on a fresh database build. That is an example of how you are introducing risk when changing your changelog file.
-Suppose instead you have a "cart" table that is created in one changeSet, then a "promo_code" column is created in another and an "abandoned" flag is created in another.
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-One option would be to combine everything into a new changeSet using the existing id="1" and delete the other changeSets.
-
-{% highlight xml %}
-
-
-
- 7:f24b25ba0fea451728ffbade634f791d
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-This will work well if all existing databases have the cart table with the promo_code and abandoned columns already added. Running Liquibase against existing databases just sees that id="1" already ran and doesn't do anything new. Running Liquibase against a blank database will create the cart table with all the columns right away. Notice that we had to add the flag or existing databases will thow an error saying that id="1" has changed since it was run. Just use the checksum in the error message in the validCheckSum tag to mark that you know it changed and the new value is OK.
-
-If you have some databases where the promo_code and/or abandoned columns have not yet been added, update the original createTable as before, but use preconditions with onFail="MARK_RAN" to handle cases where the old changeSet ran while still not adding the columns again if the new changeSet ran.
-
-
-{% highlight xml %}
-
-
-
-
- 7:f24b25ba0fea451728ffbade634f791d
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- {% endhighlight %}
-
-Now, on existing databases that have all 3 changeSets already ran, Liquibase will just continue on as before. For existing databases that have the old cart definition, it will see that the columns don't exist for id="2" and id="3" and execute then as usual. For blank databases, it will create the table with the promo_code and abandoned columns and then in id="2" and id="3" it will see that they are already there and mark that they have ran without re-adding the columns. A word of warning, however: using preconditions will add a performance overhead to your update executions and are ignored in updateSQL mode because Liquibase cannot know how applicable they are when changeSets have not actually executed. For that reason it is best to avoid them if possible, but definitely use them when needed. Preconditions also add complexity to your changelog which will require additional testing so keep that in mind when deciding whether to modify your changelog logic. Sometimes it is easiest and safest to wait until all your databases have the columns and then modify the changeSets to avoid the preconditions.
-
-
-The cart/promo_code/abandoned example shows some basic patterns you can use when modifying existing changeSets. Similar patters can be used to optimize whatever your bottlenecks are. Just remember when you change one changeSet, it can affect other changeSets below which may need to be modified as well. This can easily spider out of control so be mindful of what you are doing.
-
-
-If you end up finding that it will work best to completely restart your changelog, see http://www.liquibase.org/documentation/existing_project.html which describes how to add Liquibase to an existing project (even if that project was previously managed by Liquibase).
-
-
-(Originally posted to DZone)
diff --git a/_posts/2015-06-15-liquibase-downloads-moved-off-sourceforge.md b/_posts/2015-06-15-liquibase-downloads-moved-off-sourceforge.md
deleted file mode 100644
index c9a7f5a4a..000000000
--- a/_posts/2015-06-15-liquibase-downloads-moved-off-sourceforge.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Downloads Moved Off SourceForge
----
-# Liquibase Downloads Moved Off SourceForge
-
-When I first released Liquibase as open source in 2006, Sourceforge was the obvious place to host the project. Over the years, however, I've been slowing shifting functionality off sourceforge to liquibase.jira.com, github.com/liquibase and this blog.
-
-
-For the last few years, the only thing remaining on SourceForge was the download file hosting. Given the recent issues SourceForge has had with GIMP, Nmap, and others it is time to move the file downloads off as well. Users entrust Liquibase with their most valuable asset--their data. I want to ensure that trust is sound which is why I am moving the download source.
-
-
-What impact does this have? Very little. The main Liquibase download page is still http://liquibase.org/download and there have been no changes to that page except where the links point. If you were one of the few people who went to the sourceforge project page to download the files, they are no longer available and you must now go to the liquibase.org/download page instead.
diff --git a/_posts/2015-06-18-blog-hosting-moved.md b/_posts/2015-06-18-blog-hosting-moved.md
deleted file mode 100644
index d4978494f..000000000
--- a/_posts/2015-06-18-blog-hosting-moved.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Blog Hosting Moved
----
-# Liquibase Blog Hosting Has Moved
-
-I've moved the blog hosting off a wordpress server and am now hosting it on GitHub along with the rest of www.liquibase.org.
-
-All of the existing content on blog.liquibase.org has been moved over and reformatted. URLs to previous posts should be the same **except** for using www.liquibase.org as the host instead of blog.liquibase.org. Requests to blog.liquibase.org should automatically redirect to the new site.
-
-For those subscribing to the RSS feed, the feed URL changed from blog.liquibase.org/feed to www.liquibase.org/rss.xml but I did set up a redirect which most readers will hopefully follow.
-
-Finally, the new setup does not support blog comments. That is OK with me because I prefer people to use [forum.liquibase.org](http://forum.liquibase.org), [liquibase.jira.com](http://liquibase.jira.com) or even [@liquibase](https://twitter.com/liquibase) for discussion.
-
-If you run into any problems with the conversion, let me know.
\ No newline at end of file
diff --git a/_posts/2015-06-24-liquibase-3-4-0-released.md b/_posts/2015-06-24-liquibase-3-4-0-released.md
deleted file mode 100644
index bd633e5f2..000000000
--- a/_posts/2015-06-24-liquibase-3-4-0-released.md
+++ /dev/null
@@ -1,180 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.4.0 Released
----
-# Liquibase 3.4.0 Released
-
-Liquibase 3.4.0 has been released and is working it's way through the Maven mirrors.
-
-Downloads are available at [http://liquibase.org/download](/download). Question or comments can be directed [here](http://liquibase.org/community)
-
-
-Lots of good things in 3.4.0, but some highlights include:
-
-### You can now save snapshots and later reuse them for diff, generateChangeLog, and more
-
-We previously added the ability to use "offline" databases which allows you to specify a url of "offline:mysql" for updateSql.
-With 3.4.0, there is a new `--snapshotFormat=json` attribute you can pass to the snapshot command which will output the snapshot in machine-readable JSON.
-
-{% highlight console %}
-liquibase --url=jdbc:mysql://localhost/lbcat snapshot --snapshotFormat=json > snapshot.json
-{% endhighlight %}
-
-You can then use that snapshot with offline mode and any snapshot operations will use what is in the snapshot file as the database state.
-
-- **liquibase --url=jdbc:mysql://localhost/lbcat --referenceUrl=offline:mysql?snapshot=path/to/snapshot.json diff** will compare the stored snapshot with the current database state
-- **liquibase --url=offline:mysql?snapshot=path/to/snapshot.json diff --referenceUrl=offline:mysql?snapshot=path/to/older-snapshot.json diff** will compare two snapshots
-- **liquibase --url=offline:mysql?snapshot=path/to/snapshot.json generateChangeLog** will generate a changelog based on what is in the snapshot
-- **liquibase --url=jdbc:mysql://localhost/lbcat --referenceUrl=offline:mysql?snapshot=path/to/snapshot.json diffChangeLog** will generate a changelog based on what is new in the real database compared to what is in the snapshot.
-
-### Changelog properties can be defined as local to the changelog, not global
-
-Previously, changelog properties were "write once" and global. Meaning that once you define a property, it cannot be overridden and is applicable to all changelogs.
-
-You can now use the `global="false"` flag in properties defined in a changeSet and the property will only apply to that changeLog.
-
-{% highlight xml %}
-
-
-
-
-{% endhighlight %}
-
-The type varchar_type will be set to NVARCHAR across all changelog files, but the boolean_type value will only be BIT within this file and will be undefined elsewhere.
-
-### Index descending can be more easily defined
-
-Previously, if you wanted to control if an index is ASC or DESC you needed to use modifySql or just list the column name as "name DESC". There is now a "descending" boolean flag that can be specified in createTable and createIndex changes.
-
-{% highlight xml %}
-
-
-
-
-{% endhighlight %}
-
-### Performance improvements
-
-There was significant work done to improve snapshot time as well as loaddata. The metadata queries were improved and the amount of metadata that needs to be read for some operations was greatly decreased.
-
-The larger your databases are, the more of an improvement you should see.
-
-### New tagExists command
-
-Are you wondering if you have already used a given tag? Use `liquibase tagExists tagName` to find out.
-
-### Full Release Notes
-
-Thanks to everyone who helped with [all these issues](https://liquibase.jira.com/jira/secure/ReleaseNote.jspa?projectId=10020&version=11960)
-
-- [CORE-14] - Dropping default values with MS-SQL
-- [CORE-822] - Add a tag to add/update table/column remarks
-- [CORE-864] - loaddata performance enhancement
-- [CORE-1411] - MariaDB support
-- [CORE-2254] - Ability to save snapshot for later comparison
-- [CORE-2257] - Ability to use a previously saved database snapshot in diff and generateChangeLog
-- [CORE-2302] - Add ability to load nested object/collection properties and BigDecimal properties automatically
-- [CORE-2306] - Support passing in a script for rollback to override rollback logic included in the changelog
-- [CORE-2308] - Track changeSet contexts and labels in databasechangelog table
-- [CORE-2345] - Add XML Type
-- [CORE-419] - Allowing ASC and DESC in index definitions
-- [CORE-562] - Allow naming of not null constraints
-- [CORE-715] - indexExists does a full snapshot
-- [CORE-1731] - Support autoincrement in oracle 12c
-- [CORE-2124] - Ability to pass properties to a JDBC driver required
-- [CORE-2132] - Error message for missing sqlFile reference should be more descriptive
-- [CORE-2147] - HsqlDatabase should emit uppercase names when quoting reserved words to preserve case insensitivity
-- [CORE-2171] - New ChangeExecListener.runFailed method
-- [CORE-2177] - Support NOT(X) syntax for labels
-- [CORE-2185] - Few fields needs to be changed as protected and need additional field in RanChangeSet
-- [CORE-2217] - Add DataTypeFactory support for delimited data type names, improve resolution of MSSQL data types
-- [CORE-2228] - New usingIndexName attribute on addPrimaryKey
-- [CORE-2236] - Support .yml extension in YamlChangeLogSerializer
-- [CORE-2244] - Handle generating SQL Server DDL where ANSI NULL Default is false
-- [CORE-2249] - Index and UniqueConstraint equivalence check should take name into account
-- [CORE-2288] - Do not check/updatedatabasechangelog table on status
-- [CORE-2292] - New tagExists command for command line
-- [CORE-2298] - Allow HSQL to use defaultValueComputed for certain allowed functions on datetime type columns
-- [CORE-2299] - Add capability to ignore missing or empty folder with includeAll
-- [CORE-2307] - ChangeLog table name option in command line tool
-- [CORE-2309] - global/local properties on changesets
-- [CORE-2320] - MinGW (Git Bash) support for shell
-- [CORE-2334] - Disable CREATE TABLE DATABASECHANGELOG generation when running on OfflineConnection
-- [CORE-2336] - Use a grammer for parsing SQL rather than regexps
-- [CORE-2358] - Improve data types for Liquibase tables in MSSQL
-- [CORE-2359] - Consistently read dataTypeId for all databases
-- [CORE-2363] - Improve robustness of MSSQL database case-insensitivity check
-- [CORE-2371] - Improve Oracle snapshot performance
-- [CORE-2386] - Set the connection default catalog/schema if defaultCatalogName or defaultSchemaName is set
-- [CORE-2397] - MSSQL View Snapshot should not use sp_helptext
-- [CORE-2399] - DBDoc improvements
-- [CORE-2404] - Ability to preserve TEXT type in mssql snapshot and update
-- [CORE-842] - Tag database not taking orderexecuted into account
-- [CORE-1296] - drop column on ms sql server
-- [CORE-1424] - SQL Generation ignores DATETIME parameters
-- [CORE-1542] - Sequence is dropped not until a second run of dropAllDatabaseObjects on PostgreSQL
-- [CORE-1738] - loadData from csv fails for boolean column (if another column present)
-- [CORE-1749] - Update change command does not respect whereParams
-- [CORE-1803] - DropAll doesn’t delete sequences if they are used as default value in postgres
-- [CORE-1904] - Slow indexExists performance in Oracle
-- [CORE-1924] - SQLServer diff - DATETIME2 not being handled correctly
-- [CORE-2005] - /usr/bin/liquibase: Syntax error: "else" unexpected
-- [CORE-2018] - Quotes stripped from index filter_conditions on snapshot
-- [CORE-2019] - Comments in empty rollback prevent execution
-- [CORE-2041] - Escaping of reserved keywords in HSQLDB
-- [CORE-2096] - DiffChangeLog with changed indexes generates drop/add in the wrong order
-- [CORE-2109] - dropAll fails for statements the database requires to run non-transactionally
-- [CORE-2113] - Informix text datatype fixes
-- [CORE-2133] - Oracle: GenerateChangeLog of a table with DEFAULT VALUE NULL creates defaultValueComputed="NULL"
-- [CORE-2167] - Issues with generateChangeLog of unique constraints on DB2
-- [CORE-2169] - offline mode seems non-deterministic
-- [CORE-2178] - Fatal exception acquiring lock in SQL Server databases with case-sensitive collation
-- [CORE-2196] - Ant: "Unable to update database." without explanation
-- [CORE-2209] - Oracle snapshot sometimes creates "GENERATED ALWAYS AS (null)"
-- [CORE-2211] - Liquibase tries to execute commented lines in custom SQL file
-- [CORE-2219] - DB2 for zOs - adding primary key always emits REORG but REORG does not exist on Db2 for zOs
-- [CORE-2222] - TIMESTAMP parameters dropped for PostgreSQL
-- [CORE-2224] - Index uniqueness is not always recognized correctly
-- [CORE-2227] - CLONE - UpdateSQL needs to append a "/" to the end of createProcedure for Oracle
-- [CORE-2232] - Support schema other than public on PostgreSQL
-- [CORE-2233] - Oracle Timestamp precision lost in generateChangeLog
-- [CORE-2234] - columnExists precondition could be much faster (Oracle, mssql)
-- [CORE-2237] - YamlChangeLogSerializer does not correctly serialize a changeset
-- [CORE-2251] - Adding column with type DATETIME doesn't work for PostgreSQL
-- [CORE-2252] - XMLChangeLogSerializer writes array object for rollback tag content
-- [CORE-2253] - Handle oracle varchar <-> clob conversions in diffChangeLog
-- [CORE-2256] - Drop Sequences before Tables
-- [CORE-2266] - DiffChangeLog: Invalid changelog when a primary key backing index is changed
-- [CORE-2267] - Rollback fails for mixed-case objects created with QUOTE_ALL_OBJECTS
-- [CORE-2270] - Doubledash inside quoted text causes parsing error
-- [CORE-2271] - CLONE - DiffChangeLog: Invalid changelog when a unique constraint backing index is changed
-- [CORE-2272] - DiffChangeLog must drop foreign keys before primary keys
-- [CORE-2273] - Oracle char column snapshot not differentiating between a default value of 0 and '0'
-- [CORE-2275] - YAML update fails with Unexpected error running Liquibase: java.util.LinkedHashMap cannot be cast to java.util.List
-- [CORE-2281] - Oracle snapshot performance issue with many multiple views
-- [CORE-2291] - ObjectQuotingStrategy not reset correctly after changeSet
-- [CORE-2295] - includeAll tries to load all files instead only *.xml
-- [CORE-2300] - Unsigned Int / Bigint cannot be created
-- [CORE-2305] - Snapshot output too verbose
-- [CORE-2316] - Data type registry occasionally returns wrong data type implementation
-- [CORE-2321] - Liquibase tag command tags too much
-- [CORE-2324] - diffChangeLog does not handle changes in sequence incrementBy, maxValue or ordered
-- [CORE-2331] - Support for MSSQL collation in data type description broken
-- [CORE-2340] - Add support for extensions to override the built-in change log, snapshot serializers
-- [CORE-2355] - Improve updateSQL performance
-- [CORE-2361] - preConditions, rollback, property, include, includeAll cannot be serialized
-- [CORE-2373] - Local DTD files not found in subdirectory
-- [CORE-2378] - Adding a new "CustomChange" triggers ClassNotFoundException
-- [CORE-2380] - Support reading of gzip files
-- [CORE-2381] - Fix unique constraint generator for informix
-- [CORE-2383] - Change formatted SQL stripComments default from "true" to "false"
-- [CORE-2385] - IncludeAll does not work when runing liquibase from inside a jar
-- [CORE-2387] - dropPrimaryKey without constraint name on sql server doesn't query schema correctly
-- [CORE-2388] - Views not equal in different schemas
-- [CORE-2390] - NullPointerException when generating changelog
-- [CORE-2391] - column type doesn't respect unsigned
-- [CORE-2393] - changeSet contexts created with maven generateChangeLog are in parentheses
-- [CORE-2401] - MSSQL handling timestamp according to sql standard, not sqlserver usage
-- [CORE-2402] - Oracle NCLOB defaultValues not read correctly
-
diff --git a/_posts/2015-07-02-without-a-connection.md b/_posts/2015-07-02-without-a-connection.md
deleted file mode 100644
index be819bbee..000000000
--- a/_posts/2015-07-02-without-a-connection.md
+++ /dev/null
@@ -1,70 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Without a Database Connection
----
-# Liquibase Without a Database Connection
-
-There are many, many different processes and requirements companies have for managing their database schemas. Some allow the application to directly manage them on startup, some require SQL scripts be executed by hand. Some have schemas that can differ across customers, some have only one database to deal with.
-
-For people who prefer to execute SQL themselves, Liquibase has always supported an "updateSQL" mode which does not update the database but instead outputs what would be run. This allows developers and DBAs to know exactly what will be ran and even make modifications as needed before actually executing the script.
-
-Before version 3.2, however, Liquibase required an active database connection for updateSQL. It used that connection to determine the SQL dialect to use and to query the DATABASECHANGELOG table to learn what changeSets have already been executed.
-
-### Controlling updateSql SQL Syntax
-
-With version 3.2, Liquibase added a new "offline" mode. Instead of specifying a jdbc url such as `jdbc:mysql://localhost/lbcat` you can use `offline:mysql` or `offline:postgresql` which lets Liquibase know what dialect to use. For finer dialect control, you can specify parameters like `offline:mysql?version=3.4&caseSensitive=false`
-
-Available dialect parameters:
-
-- **version:** Standard X.Y.Z version of the database
-- **productName:** String description of the database, like the JDBC driver would return
-- **catalog:** String containing the name of the default top-level container (‘database’ in some databases ‘schema’ in others)
-- **caseSensitive:** Boolean value specifying if the database is case sensitive or not
-
-### Tracking History With CSV
-
-These parameters let Liquibase know what SQL to generate for each changeSet, but without an active database connection you cannot rely on the DATABASECHANGELOG table to track what changeSets have already been ran. Instead, offline mode uses a CSV file which mimics the structure of the DATABASECHANGELOG table.
-
-By default, Liquibase will use a file called "databasechangelog.csv" in the working directory, but it can be specified with a "changeLogFile" parameter such as `offline:mssql?changeLogFile=path/to/file.csv`
-
-It is up to you to ensure that the contents of the csv file match what is in the database. Running updateSQL automatically appends to the CSV file under the assumption that you will apply the SQL to the database. Since the csv file matches a particular database, it isn’t something you normally would store or share under version control because every database can (and probably will) be in a different state. If you do store the files in a central location, you will probably want to at least have a separate file for each database.
-
-By default, the SQL generated by updateSql in offline mode will still contain the standard DATABASECHANGELOG insert statements, so each database that you apply the SQL to will still have a correct DATABASECHANGELOG table. This means that you can switch between a direct-connection update and offline updateSQL as needed. It also means that you can also extract the current contents of the DATABASECHANGELOG table to a CSV file and use that as the file passed to the offline connection to ensure you have the right contents in the file.
-
-If you do not want the DATABASECHANGELOG table SQL included in updateSQL output, there is an "outputLiquibaseSql" parameter which can be passed in your offline url.
-
-Possible outputLiquibaseSql values:
-
-- **"none"** will output no DATABASECHANGELOG statements
-- **"data_only"** will output only INSERT INTO DATABASECHANGELOG statements
-- **"all"** will output CREATE TABLE DATABASECHANGELOG if the csv file does not exist as well as INSERT statements (default value)
-
-### Offline Snapshots
-
-The new 3.4.0 release of Liquibase expands The new 3.4.0 release of Liquibase expands offline support with a new "snapshot" parameter which can be passed to the offline url pointing to a saved database structure. Liquibase will use the snapshot anywhere it would have normally needed to read the current database state. This allows you to use preconditions and perform diff and diffChangeLog operations without an active connection and even between snapshots of the same database from different points in time.
-
-To create a snapshot of your live databases, use the `—snapshotFormat=json` parameter on the "snapshot" command.
-
-Command line example:
-
-{% highlight console %}
-$ liquibase --url=jdbc:mysql://localhost/lbcat snapshot --snapshotFormat=json > snapshot.json
-{% endhighlight %}
-
-or
-
-{% highlight console %}
-$ liquibase --url=jdbc:mysql://localhost/lbcat --outputFile=path/to/output.json snapshot --snapshotFormat=json
-{% endhighlight %}
-
-NOTE: currently only "json" is supported as a snapshotFormat.
-
-You can then use that file with your offline url and any snapshot operations will use it as the database state.
-
-- **liquibase --url=jdbc:mysql://localhost/lbcat --referenceUrl=offline:mysql?snapshot=path/to/snapshot.json diff** will compare the stored snapshot with the current database state
-- **liquibase --url=offline:mysql?snapshot=path/to/snapshot.json diff --referenceUrl=offline:mysql?snapshot=path/to/older-snapshot.json diff** will compare two snapshots
-- **liquibase --url=offline:mysql?snapshot=path/to/snapshot.json generateChangeLog** will generate a changelog based on what is in the snapshot
-- **liquibase --url=jdbc:mysql://localhost/lbcat --referenceUrl=offline:mysql?snapshot=path/to/snapshot.json diffChangeLog** will generate a changelog based on what is new in the real database compared to what is in the snapshot.
-
-*Originally posted to [java.dzone.com](http://java.dzone.com/articles/using-liquibase-without)*
diff --git a/_posts/2015-07-23-executing-liquibase.md b/_posts/2015-07-23-executing-liquibase.md
deleted file mode 100644
index 027ffba59..000000000
--- a/_posts/2015-07-23-executing-liquibase.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Executing Liquibase - 3 Use Cases
----
-# Executing Liquibase: 3 Use Cases
-
-Once you've created a [database changelog file](/documentation/databasechangelog.html), what is the best way to run it? As always, it depends on what works best for you. There are three main ways to run Liquibase: "automatically on startup", "manually as needed", or "Just give me the SQL and I'll do it myself". All three work with any changelog file, so use the method (or combination of methods) which works best for your project.
-
-### Automatic Deployment
-
-The easiest way to run Liquibase is to set it to run automatically on startup. Once set up, your database state always matches what your code expects and you have no manual steps to forget. This method works best in environments where you have less control over the deployment process or if you want a simpler deployment process.
-
-I've seen this method used for web applications that use Continuous Delivery and have an automated release process from code check in through live production which gets executed multiple times per day. I've also seen this method used in packaged applications that are shipped to customers to make the database management portion completely transparent.
-
-Don't worry if you have multiple servers pointing to the same database. Liquibase uses a DATABASECHANGELOGLOCK table to ensure that only one instance of Liquibase runs at a time. Even if you have a cluster of servers all coming online at the same time and all automatically running Liquibase, the lock table will ensure that they will not all try to update the database concurrently and cause problems.
-
-Liquibase ships with two hooks to automatically update your database on startup: a [servlet listener](/documentation/servlet_listener.html) and a [Spring bean](/documentation/spring.html).
-
-If neither of those hooks fit with your application, you can always call the Liquibase Java API directly. The most straightforward way of running Liquibase directly looks like this:
-
-{% highlight java %}
-java.sql.Connection connection = openConnection(); //your openConnection logic here
-
-Database database = DatabaseFactory.getInstance().findCorrectDatabaseImplementation(new JdbcConnection(connection));
-
-Liquibase liquibase = new liquibase.Liquibase("path/to/changelog.xml", new ClassLoaderResourceAccessor(), database);
-
-liquibase.update(new Contexts(), new LabelExpression());
-{% endhighlight %}
-
-This code will create an instance of the liquibase.Liquibase façade and run the update() method which simply updates the database to match the passed changelog. There are many other methods on the Liquibase façade which can also be used if you are looking to automate Liquibase in different ways.
-
-### Manual Deployment
-
-If automatic database updates don't work well for you, you can execute Liquibase on demand. Liquibase ships with a [command line application](/documentation/command_line.html) which supports both Windows and Linux. It also ships with an [Ant task](/documentation/ant/index.html) and a [Maven goal](/documentation/maven/index.html) for those who use those tools. These interfaces allow you to execute Liquibase commands whenever you need, without being tied to application startup.
-
-One common use for the Ant and/or Maven interface is to integrate Liquibase into your build process. This allows you to catch errors in your changelog earlier, and also gives you a database which automated tests can be ran against. Developers can run the same tasks against their local environment for initial development and for fixing issues. Remember: [contexts](/documentation/contexts.html) work well for embedding test data in your changelog and only deploying it to test environments.
-
-You may also prefer to run Liquibase directly with more complex release processes that are designed to eliminate downtime. For example, if you make your database changes compatible with the existing codebase (no DROP commands), you can run Liquibase update while the old version of your site is still running. Once it has successfully updated, then begin a staged rollout of new code across your cluster.
-
-### Executing SQL
-
-Manual updates with Liquibase allow you to control WHEN the database is updated, but WHAT is actually executed is still managed completely by Liquibase. For those who need to know exactly what is being done to their database, Liquibase supports an "updateSQL" mode in the command line, Ant, and Maven interfaces. When running updateSQL, Liquibase will simply output the SQL it would normally have ran. The output includes both the SQL to update your database and also the SQL to keep the DATABASECHANGELOG table up to date. Inspect the output as you need then execute it through whatever database tools you prefer. After running the SQL, your database will be in the correct state, and Liquibase will know what was ran and so future updateSQL calls will include only new changeSets.
-
-### Mix and Match
-
-All the above methods can also be mixed and matched as needed to handle whatever schema management needs you may have. Some projects use automatic deployment for development and initial QA, then updateSQL for final QA and production. Some shipped products automatically run Liquibase on startup, but hotfixes are handled through a more manual process. Others automatically run Liquibase all the way through production, but the executed SQL is automatically saved and is watched by DBAs throughout the release progression to ensure nothing unexpected is happening.
-
-No matter what your schema deployment needs are, you should be able to find a way to manage them with Liquibase.
\ No newline at end of file
diff --git a/_posts/2015-07-28-liquibase-3-4-1-released.md b/_posts/2015-07-28-liquibase-3-4-1-released.md
deleted file mode 100644
index c45ef5fa9..000000000
--- a/_posts/2015-07-28-liquibase-3-4-1-released.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.4.1 Released
----
-# Liquibase 3.4.1 Released
-
-Bugfix release Liquibase 3.4.1 is now available from [liquibase.org/download](/download) and through the Maven repositories.
-
-### Fixes include:
-
-- improvements to includeAll logic
-- better handling of older-version DATABASECHANGELOG table structures with updateSQL and status
-- improved data type handling
-- extensions containing custom loggers should work again
-- Correctly detect "Sybase IQ"
-
-### Full changelog:
-
-- [CORE-998] - Changing index columns leads to wrong output order in the change log xml file.
-- [CORE-2104] - ConcurrentModificationException iterating over System.getProperties().entrySet()
-- [CORE-2385] - IncludeAll does not work when runing liquibase from inside a jar
-- [CORE-2405] - Collation not preserved, depending on configuration
-- [CORE-2406] - Escaped built-in data types should be lower case
-- [CORE-2408] - Unknown column 'LABELS' in 'field list'
-- [CORE-2410] - Snapshot should not include paramaters for MSSQL geometry, geography or sql_variant types
-- [CORE-2411] - BLOB string default values not quoted
-- [CORE-2412] - Handle Oracle BFILE types
-- [CORE-2414] - CLONE - generateChangeLog creates DOUBLE(22) instead of double in MySql
-- [CORE-2415] - Custom Logger configuration does not work anymore
-- [CORE-2416] - Diff drops and creates primary keys for all tables
-- [CORE-2418] - Liquibase 3.4.0 tries to do INSERT instead of UPDATE-Statements with Postgres
-- [CORE-2421] - MySQL column sizes are off by 1 in BIGINT and INT for diffChangeLog
-- [CORE-2422] - Liquibase intialisation failed
-- [CORE-2423] - Sybase IQ : strange procedure called
-- [CORE-2426] - Default schema name missing quotes.
-- [CORE-2427] - Better handle MSSQL stored procedures with a different defaultSchema and replaceOnExists=true
-- [CORE-2428] - liquibase 2.0.3 to 3.3.3
-- [CORE-2435] - includeSystemClasspath switch actually includes SystemClassLoader if false
-- [CORE-2436] - Logging in ClassLoaderResourceAccessor prevents installation of custom Logger
-- [CORE-2437] - Index.toString() contains "unique" if and only if index is NOT unique
-- [CORE-2438] - DeleteGenerator does not handle parameter names and values with $ or \ properly
-- [CORE-2440] - Not possible to override DefaultLogger using a Logger in a non-liquibase package.
-- [CORE-2441] - Creation of foreign key fails in MySQL if database name contains dashes
-- [CORE-2442] - Creating MD5 checksum fails if changeSet id contains the character "?"
-- [CORE-2443] - Liquibase 3.4.0 ignores third party loggers in certain situations
-- [CORE-2446] - endDelimiter splitting does not work in plain SQL files (regression)
-- [CORE-2452] - Index names should be quoted on SQL Server
-- [CORE-2458] - loadUpdateData will not update
-- [CORE-2460] - Postgres index names cannot include schema name
-- [CORE-2433] - quoting error in table creation
-- [CORE-2359] - Consistently read dataTypeId for all databases
-- [CORE-2419] - Support fluent/builder-style change properties
-- [CORE-2449] - Correctly detect "Sybase IQ"
-- [CORE-2450] - Non-bash /bin/sh gives "[[ not found" error
-- [CORE-2451] - SQL scripts should have "USE database" in the header on SQL Server
-- [CORE-2453] - Informix: Return null for connection schema name
-- [CORE-2459] - Un-change Formatted SQL stripComments default back to true
-- [CORE-2461] - Don't do DATABASECHANGELOG ALTER statements if column types are different
\ No newline at end of file
diff --git a/_posts/2015-08-04-liquibase-status-aug2015.md b/_posts/2015-08-04-liquibase-status-aug2015.md
deleted file mode 100644
index 675e95566..000000000
--- a/_posts/2015-08-04-liquibase-status-aug2015.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Status - Aug 2015
----
-# Liquibase Status - August 2015
-
-This is the first in a planned monthly post designed to give a better window into Liquibase development and the Liquibase community. I'd appreciate any feedback you have on how helpful (or not) it is and/or any suggestions you have.
-
-My work on Liquibase was split last month between a 3.4.1 release and continuing work on Liquibase 4.0. The full scope (and timeline) of 4.0 is still being determined, but the high-level goals are to:
-
-- Simplify and standardize the codebase
-- Improve the testability
-- Make larger internal API changes to support new functionality
-
-So far, the 4.0 work has focused on simplifying the Statement/Change/Generator/Snapshot logic and improving the testing of the interaction between Liquibase and the database. For more information and to help review the code so far, see [http://forum.liquibase.org/#Topic/49382000001343003](http://forum.liquibase.org/#Topic/49382000001343003)
-
-The goal of 4.0 is to have no end-user breaking changes, but there will be API changes that will affect extension writers. Documentation on the upgrade process will be part of the release.
-
-Beyond codebase changes, I switched the blog hosting from a separate server to being a part of the [liquibase.org github pages sites](https://github.com/liquibase/liquibase.github.com). Anyone using an RSS reader should have been redirected, and for everyone else the main difference should be posts now showing in the left navigation of liquibase.org and a more consistent design. For me, I now have one less server to maintain which is always good.
-
-I also recently became the proud owner of the [@liquibase](https://twitter.com/liquibase), twitter account so feel free to follow and/or contact me there.
-
-Finally, I want to use each monthly update as an opportunity to recognize a different contributor. As an open source project, Liquibase is a group effort with usually very little recognition.
-
-This month I'd like to thank [Mark Chesney](https://github.com/mches). Over the last few months he has sent nearly [50 pull requests](https://github.com/liquibase/liquibase/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Amches+) and has not only done a good job of managing the corresponding [liquibase.jira.com issues](https://liquibase.jira.com/secure/ViewProfile.jspa?name=mches), but has also helped answer questions, find work-arounds, and triage issues on other issues as well. Most of his work has centered around improving MS SqlServer support, and I appreciate all he has done.
-
-
diff --git a/_posts/2015-08-18-survey-2015.md b/_posts/2015-08-18-survey-2015.md
deleted file mode 100644
index 6f7290367..000000000
--- a/_posts/2015-08-18-survey-2015.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Survey 2015
----
-# Liquibase Survey 2015
-
-One problem with running an open source project is that we don't really have "customers" to contact for feedback and product suggestions. I can always just add features that **I** think make sense, but one thing I've learned is that people use Liquibase in amazing ways I would never have imagined.
-
-That is where the **[Liquibase survey](http://goo.gl/forms/TNXBl5GsPv)** comes in: it is your chance to provide feedback on how you use Liquibase and what is important to you so that I can better prioritize efforts over the next year.
-
-## Your participation and time is greatly appreciated ##
-
-### -----> [Liquibase Survey 2015 Form](http://goo.gl/forms/TNXBl5GsPv) <----- ###
-
-If you know others that use Liquibase, please forward them the survey as well. Even better, if you know someone who is NOT using Liquibase, send them the survey as well.
-
-The more information I can gather the better picture I will have.
-
-**Survey runs until September 18th, 2015**
\ No newline at end of file
diff --git a/_posts/2015-09-01-liquibase-status-sept2015.md b/_posts/2015-09-01-liquibase-status-sept2015.md
deleted file mode 100644
index 79b057e1c..000000000
--- a/_posts/2015-09-01-liquibase-status-sept2015.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Status - Sep 2015
----
-# Liquibase Status - Sep 2015
-
-If you missed last month, I've started a monthly status post to give a better window into Liquibase development and the Liquibase community. I'd appreciate any feedback you have on how helpful (or not) it is and/or any suggestions you have.
-
-New this month is the Liquibase 2015 Survey. Since I don't have direct contact with the majority of Liquibase users, it is my best opportunity to understand how Liquibase is actually used in the wild to help prioritize features.
-If you've not filled out the survey yet, you can find it at [http://goo.gl/forms/TNXBl5GsPv](http://goo.gl/forms/TNXBl5GsPv). The survey ends September 18th, 2015.
-
-No new releases in the last month, but I'm planning on a 3.4.2 bugfix release in September.
-
-Some interesting statistics from the liquibase.org traffic
-
-- We get nearly 14,000 sessions per week
-- Bing and DuckDuckGo are neck and neck for referrals, but Google still accounts for 98.6% of search engine traffic
-- Nearly 15% of people are visiting from a Linux machine and more people use Android than iOS
-- Over 68% use Chrome while less than 4% use IE
-
-This month's "contributor of the month" is [Matt Bertolini](https://github.com/mattbertolini). He saw that the Ant integration was getting fairly out of date and took it upon himself to refactor it.
-Not only was the [pull request one of the best I've seen](https://github.com/liquibase/liquibase/pull/275) but he watched for related Jira issues and forum questions after his code was released and addressed any questions and problems that came up.
-While I always appreciate pull requests, the on-going maintenance of new features and helping other users with related problems is at *least* as valuable. As contributor of the month, Matt gets a 13,000 mAh USB battery graciously donated by [datical.com](http://datical.com) in addition to my thanks.
\ No newline at end of file
diff --git a/_posts/2015-09-10-liquibase-without-changelogs.md b/_posts/2015-09-10-liquibase-without-changelogs.md
deleted file mode 100644
index 69c24cf4f..000000000
--- a/_posts/2015-09-10-liquibase-without-changelogs.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase Without Changelogs
----
-# Liquibase Without Changelogs
-
-Early on, Liquibase only supported XML changelogs with each changeSet listed in it. There are many advantages to using that setup, but there are now many different ways to store your database changes.
-
-One way to manage your changes is to store them in individual SQL files. Some people prefer this setup because it is similar to other tools they have used, because they find SQL more natural to work with than XML, or they prefer to work with smaller files in a directory than changeSets stored in a large file. It is also helpful when migrating to Liquibase from an older system that manages changes as individual files.
-
-### Master Changelog
-
-To bootstrap the process, you need a master changelog file that uses the includeAll command. I know the title said "Liquibase Without Changelogs," but once you have created this file you never have to touch it again.
-
-**File "com/example/liquibase/changelog.xml"**
-
-{% highlight html %}
-
-
-
-
-
-
-{% endhighlight %}
-
-The includeAll command is telling Liquibase to run all the SQL files in the "com/example/liquibase" directory.
-
-Now, when you run `liquibase --changeLogFile=com/example/liquibase/changelog.xml update` Liquibase will look for files with an SQL extension in com/example/liquibase and treat each as a changeSet. The files will be executed in alphabetical order.
-
-### Example Usage
-
-Create a file "com/example/liquibase/0010-create-address.sql" containing
-
-{% highlight sql %}
-
-create table address (id int primary key, line1 varchar(20), line2 varchar(20));
-
-{% endhighlight %}
-
-Now run liquibase update and you will see an "Update Successful" message and the new address table in your database.
-
-If you run liquibase update update again, Liquibase knows that the SQL file already ran and does not try to re-create your table.
-
-You can see what Liquibase is tracking by running select id, author, filename from databasechangelog and you will see a row with id="raw", author="includeAll", filename="com/example/liquibase/0010-create-address.sql". The SQL file is being managed like any other changeSet, using a generated author of "includeAll" and id of "raw".
-
-Now create another file "com/example/liquibase/0020-address-insert.sql" containing:
-
-{% highlight sql %}
-
-insert into address (id, line1, line2) values (1, '121 Main Ave', null);
-insert into address (id, line1, line2) values (2, '662 Broadway', 'Suite 3317');
-insert into address (id, line1, line2) values (3, '412 Riverview', null);
-
-{% endhighlight %}
-
-and run liquibase update again.
-
-This time data will be inserted into the table and if you select from databasechangelog there will now be a second row containing id="raw", author="includeAll", filename="com/example/liquibase/0020-insert-address.sql"
-
-Continue adding SQL files to build your database.
-
-### Things to consider: File Naming
-
-Liquibase simply execute files in alphabetical order and will track what has ran based on the filename.
-
-Therefore, choose a naming pattern that is easy for you to use but also leaves you open to sneak in new changeSets between existing ones down the road if you need. In the above example, I used a pattern of a zero-padded 4 digit number that increments by 10 followed by a simple description of what is in the file. The zero-padding will preserve the correct alphabetical file ordering while the incrementing by 10 allows me to add a "0011-increase-address-size.sql" file if I realize one needs to be added "before" the 0020 file. If I hit the limit of the 10 increment or the 1000 zero padded length, continue on with letters. 001a.sql will come after 0019 alphabetically.
-
-Also make sure you use a consistent case for your filenames. Some systems will sort them case sensitively and others will not, so for best portability pick a case and stick to it.
-
-### Things to consider: checksums
-
-Like all changeSets, Liquibase tracks the checksum of the changeSet when it was executed against each database. So, if you modify a SQL file after it has been executed somewhere, Liquibase will throw an error on the next update saying that the checksum has changed. Therefore, each new step in your database migration should be in its own file--don't append to an existing file.
-
-### Things to consider: transactions
-
-Like all changeSets, Liquibase will try to run each SQL file in its own transaction. Since most statements are auto-committing on most databases, it is best to have a single statement per SQL file. Otherwise, if the second statement fails but the first auto-commits, Liquibase will be in an indeterminate state due to the half-ran changeSet.
-
-### Liquibase Formatted SQL
-
-Rather than using standard SQL in your files, consider using [Liquibase-formatted SQL](http://www.liquibase.org/documentation/sql_format.html) for some or all of your files. Liquibase-formatted SQL is designed to be backwards-compatible with standard SQL but allows you more flexibility and power within Liquibase, such as the ability to run preconditions, use changelog parameters, filter statements by database or context, and more. Liquibase-formatted SQL also allows you to specify multiple changeSet blocks within a single file.
-
-To try a Liquibase-formatted file, create a file com/example/liquibase/0030-start-cart.sql
-
-{% highlight sql %}
-
---liquibase formatted sql
---changeset nvoxland:1
-create table cart (id int primary key, created_date date);
-
---changeset nvoxland:2
-create table cart_item (id int primary key, created_date date, cart_id int, line_item int, quantity int);
-
-{% endhighlight %}
-
-After running liquibase update, when you select from databasechangelog you will see a row with id="1" author="nvoxland" filename="com/example/liquibase0030-start-cart.sql" and a row with id="2" author="nvoxland" filename="com/example/liquibase0030-start-cart.sql". Because of the formatting, Liquibase is seeing each chunk of the file as a separate changeSet and any new changesets you append to the file will be handled correctly as well.
-
-*(Originally posted to the [Datical.com blog](http://www.datical.com/liquibase-without-changelogs/))*
\ No newline at end of file
diff --git a/_posts/2015-09-25-liquibase-survey-2015-results.md b/_posts/2015-09-25-liquibase-survey-2015-results.md
deleted file mode 100644
index 750ecbdb9..000000000
--- a/_posts/2015-09-25-liquibase-survey-2015-results.md
+++ /dev/null
@@ -1,163 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: 2015 Survey Results
----
-# 2015 Survey Results
-
-There were 136 responses to the 2015 Liquibase Survey. Since I'm relying on self-selection for people answering the survey, the first question is how representative is the data.
-The only two "demographic" survey questions I have alternate data points for are version used and country.
-
-### Liquibase Version
-
-Version | Survey | Maven Downloads
----- | ---- | -----
-3.4 | 44% | 12%
-3.3 | 29% | 37%
-3.2 | 8% | 4%
-3.1 | 7% | 11%
-3.0 | 3% | 8%
-2.x | 9% | 27%
-1.x | 1% | 1%
-
-Maven downloads is as good of a proxy for active users as I have since it will be including re-downloads more often.
-Based on these results, the survey results are more skewed toward people who keep their Liquibase version more up to date as you'd probably expect since they are the ones visiting liquibase.org more often and subscribing to the blog where the survey announcements were.
-
-### Country
-
-Country | Survey | Liquibase.org traffic
---- | --- | ---
-United States | 26% | 22%
-Germany | 20% | 8%
-India | 2% | 7%
-UK | 10% | 6%
-Russia | 2% | 5%
-France | 2% | 4%
-Brazil | 2% | 4%
-Canada | 3% | 3%
-Other | 34% | 41%
-
-The survey is interestingly heavy on people from Germany and under-representative of India, but otherwise seems like a reasonable cross-section.
-
-### Usage Information
-
-
-
-
-
-
-
-
-
-What I found most surprising was the length of time people have used Liquibase. For a project that was first released in 2006, I would have expected a larger contingent of people using it for longer than 4 years.
-It may be a result of newer users being most likely to visit liquibase.org and see the survey link, but it also a good sign for the project and the community that the user base is continuing to grow.
-Continued growth should be expected as well, since most people are using Liquibase daily or weekly as part of their normal development process, but many have so far only deployed to less than 1/4 of their projects.
-
-### Existing and Future Functionality
-
-
-
-
-
-
-
-One goal of the survey is to get an idea of what functionality people use and what could be improved upon. The general "how well does it meet your needs" peaks at a 4 and averages to 4, whereas the documentation averages only 3.3.
-Documentation is something that I've not spent nearly enough time on, and the results definitely confirms that. The "meets needs" response is OK, but could definitely be better.
-The extension question had 75% of people not writing extensions, so most people are making do with what ships with Liquibase vs. building their own functionality.
-
-The most helpful section of the survey was the free response questions since they gave people a chance to give specific details about what they liked and what they want improved.
-
-Some common themes in the answers included:
-
-##### What do you like most about Liquibase?
-
-- Use of non-sql XML and other formats to describe changes while still supporting SQL when needed
-- Database agnostic and independent
-- Simple/easy to use
-- Can set up automatic database updates that just work
-- Flexibility
-- Project reliability and community
-- Multiple options for defining changelogs
-
-##### What features do you wish Liquibase had?
-
-- Improved error messages and feedback
-- Improved groovy support
-- Ability to verify schemas
-- Support for more databases and database-specific functionality
-- NoSQL support
-- PostConditions
-- Looping construct
-- Consolidation of old changeSets
-- Static analysis/linting of changelogs
-
-##### What are your greatest pain points with Liquibase?
-
-- Migration of current workflow / adaption
-- Documentation
-- File encoding issues
-- Checksums
-- The logging system
-- Using Liquibase in OSGi
-- Functionality that may not work consistently across all database types
-- Lack of baselining support
-- Performance
-- Only Java-based
-- Mixed-case handling
-- Data type logic
-- Sometimes slow bugfixes and community responses
-- Required to use XML
-
-There was a lot of other great answers as well, both for specific features to add and more general suggestions.
-
-The areas for improvement generally lined up with what I was expecting, and are in the queue for upcoming releases which is always good.
-Issues with documentation appears not only as a called-out pain point, but also shows up as other issues (such as required use of XML) where existing functionality is not described well enough to be found.
-
-### Other demographics
-
-
-
-
-
-
-
-
-
-
-
-I always find real-life database usage interesting. For all the hype some databases get, Oracle squeaks out ahead of Postgresql and Mysql with a big drop-off to the rest.
-MS SqlServer is probably under-represented compared to the industry as a whole since Liquibase is Java-based, but I was also surprised at H2's popularity.
-I use H2 often while testing Liquibase because it is significantly faster for my tests than anything else, so it's good to see it is getting wider use.
-
-Not a big surprise that Java and Javascript dominated the technologies of Liquibase users, but I was surprised to see the other languages at nearly 10% usage each.
-
-I've always seen Liquibase as more of a developer-friendly tool, but was surprised to see just how dominant the use by developers are vs. other roles was. Perhaps it's all the XML that scares off everyone else...
-
-I was also surprised to see the agility responses not farther to the right given that Liquibase is an agile/refactoring type tool.
-
-### Comparisons to 2013 Results
-
-I purposefully kept the survey questions very close to the survey I did in 2013 to compare. Some highlights from comparing results:
-
-- Daily use increased from 43% to 53% while weekly use remained consistent
-- "How well does Liquibase meet your needs" increased from 3.6 to 4.0
-- "How helpful is the documentation" increased from 3.2 to 3.3
-- Database use was very consistent, other than an increase in DB2 use from 4% to 10%
-- Non-Java technology use increased from about 5% to about 10%
-- Agility increased from 3.4 to 3.5
-
-### Final Thoughts
-
-Thanks again to everyone who filled out the survey this year.
-
-While I get a good feel for how people are using Liquibase on an ongoing basis from questions asked, issues opened, and pull requests made, it is very helpful to have an alternate view of the project.
-There wasn't anything completely unexpected to alter the roadmap I have in my head, but it is also good to see that the changes I'm planning on making will address many of the pain points people are having.
-Plus, there are were several "that is a great idea, why didn't I think of that" suggestions which will be incorporated in future releases.
-
-My plan was to continue making incremental improvements to the 3.x codeline while concurrently working on a more major 4.0 release, and based on the survey results I think that plan continues to make sense.
-It appears that for the most part people are satisfied with Liquibase and it does most of what is needed. Consistency and reliability are important to them, and I don't want to throw major changes at them.
-However, while there are safe improvements such as performance and file encoding that can be made in 3.x, fully addressing things like checksums, mixed-case, and data types will require significant-enough changes that they are best wrapped up into a "you know there is going to require testing" 4.0 release.
-
-Documentation is also re-highlighted as something that needs more love as well. Liquibase is very flexible and has a lots of options, and not only does the raw features need to be better documented but how the various pieces can fit together to solve use cases and pain points needs to be better highlighted as well.
-
-If you have any question or suggestions please let me know or discuss it on the [forum](http://forum.liquibase.org/#Topic/49382000001371001).
\ No newline at end of file
diff --git a/_posts/2015-10-26-halloween-fun.md b/_posts/2015-10-26-halloween-fun.md
deleted file mode 100644
index d411ada5c..000000000
--- a/_posts/2015-10-26-halloween-fun.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Halloween Fun
----
-# Halloween Fun
-
-Halloween--the spookiest night of the year. Spookiest night for those who don't do production deployments anyway...
-
-So, for you sys admins, DBAs, and developers who know have stared down the terrors of a release night and fought the ghouls of last minute "shouldn't cause a problem" changes here are three games to make your Halloween party more fun.
-
-Each is formatted to fit standard paper, click on the images below for the full-size game.
-
-
-
-
-
-
\ No newline at end of file
diff --git a/_posts/2015-11-24-liquibase-3-4-2-released.md b/_posts/2015-11-24-liquibase-3-4-2-released.md
deleted file mode 100644
index 6fdc3de7d..000000000
--- a/_posts/2015-11-24-liquibase-3-4-2-released.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.4.2 Released
----
-# Liquibase 3.4.2 Released
-
-Bugfix release Liquibase 3.4.2 is now available from [liquibase.org/download](/download) and through the Maven repositories.
-
-### Fixes include:
-
-- Maven <skip> configuration now available
-- Improved startup performance
-- Don't fall back to the internet if multiple liquibase XSDs are found
-- improved data type handling
-- extensions containing custom loggers should work again
-
-### Full changelog:
-
-- [CORE-2328] - AbstractExecutor should implement execute(Change)
-- [CORE-2475] - Informix: Insert valueComputed not used correctly
-- [CORE-2543] - Improved support for time stamps in oracle insert change data types
-- [CORE-1778] - createSequence doesn't work on MSSQL
-- [CORE-1840] - Liquibase fails when run on a computer that can't connect to the internet
-- [CORE-2273] - Oracle char column snapshot not differentiating between a default value of 0 and '0'
-- [CORE-2285] - Code in Liquibase class inconsistent
-- [CORE-2317] - Custom ConfigurationValueProvider not working
-- [CORE-2349] - loadUpdateData does not escape column names in "ON DUPLICATE" clause
-- [CORE-2407] - Derby keywords not escaped when used as column/table names
-- [CORE-2447] - In sybase, schema is bad preixed
-- [CORE-2466] - Rollback referencing a change set in another file cannot be parsed
-- [CORE-2467] - SSO with jtds MSSQL doesn't work after 3.3.5 for update - null user error
-- [CORE-2469] - Error in method ColumnConfig.setValueNumeric(String)
-- [CORE-2470] - MSSQL: FindForeignKeyConstraintsGeneratorMSSQL doesn't honor specified schema
-- [CORE-2480] - Primary key exist works fine with 3.3.3 not with 3.4.0 in SQL SERVER
-- [CORE-2481] - Primary key creation issue with informix
-- [CORE-2482] - Number type issue with informix
-- [CORE-2484] - dropAll command crashes because it drops sequences before tables
-- [CORE-2487] - updateSql does not output anything for prepared statements
-- [CORE-2490] - If you have more than one :name token in the where clause of a delete change, you get an Exception
-- [CORE-2491] - Shouldn't a custom change produce a warning if run in updateSql mode
-- [CORE-2492] - Logger extension liquibase-slf4j no longer usable with 3.4.1
-- [CORE-2494] - Pgsql: Exporting/generating badly formatted SQL
-- [CORE-2498] - Generation of TIMESTAMP(29) causing error in PSQL log TIMESTAMP(6) WITHOUT TIME ZONE
-- [CORE-2500] - Fast check of ColumnExistsPrecondition causing transaction abort on PostgreSQL database
-- [CORE-2505] - Missing keywords for H2 database
-- [CORE-2510] - loadData on MySQL with > 50 rows fails
-- [CORE-2544] - LogFactory does not get reset
-- [CORE-2549] - Performance regression in resolving local host
-- [CORE-2554] - updateSql command fails on validation when upgrading (2.0.5 ->3.4.1)
-- [CORE-2566] - Maven - setting skip= true does not work
-- [CORE-2571] - primaryKeyExists precondition generating wrong query
-- [CORE-2576] - The 'dbms' attribute on createProcedure is not not taken into account when parsing changes
-- [CORE-2579] - dropAll failed for Oracle 12c
-- [CORE-2580] - Escape column, table and schema on ColumnExistsPrecondition
-- [CORE-2588] - Bad cast
-- [CORE-2590] - Default constraint names are not quoted
-- [CORE-2596] - DatabaseChangeLogLock race condition exists if two nodes both try to create the table
-- [CORE-2598] - Postgres generateChangeLog: "length for type varchar cannot exceed 10485760"
diff --git a/_posts/2016-02-15-liquibase-for-qa.md b/_posts/2016-02-15-liquibase-for-qa.md
deleted file mode 100644
index 08d71242b..000000000
--- a/_posts/2016-02-15-liquibase-for-qa.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase for QA Test Teams
----
-# Liquibase for QA Test Teams
-
-As a QA team member, you always make sure you are testing the current version of an application. However, it is just as important that the testing schema is correct and that there are no unexpected changes that the developers have applied to their environment that you do not know about.
-
-Beyond the simple structure of the database, it is important that QA teams ensure the data migration from one version to the next is correct. This allows test team members to verify there is no lost or corrupted data.
-
-By introducing Liquibase into your organization, QA test team members are able to know that what you are testing is what will be released--from the UI to database.
-
-### Know you have the correct database schema
-
-Liquibase [tracks which changelog statements](/documentation/databasechangelog.html) have run against each database, so you can be certain that the schema you are using for test matches what the developers expect. Even better, QA teams will know that the schema will match what goes to production so you there will be no unexpected "why wasn't this tested?" surprises.
-
-### Easier test data management
-
-Normally, test data is stored in something like CSV files which are loaded into the database after it is built. The problem with this strategy is that schema changes usually can and will break something in the data load process. Typically this leads to QA teams spending hours trying to figure out what the test data was trying to expose and then adjusting the files to match the new schema.
-
-Instead of loading the data into the final schema, build up the test data within your changelog file. Use [loadData](/documentation/changes/load_data.html) or [standard sql](/documentation/changes/sql.html) to load data into the schema as it is now, then as new schema changes are appended to the changelog the test data will be migrated just like production data. This not only QA team members from having to continually update CSV files, but also helps verify that existing data is handled correctly.
-
-Another best practice is to use [contexts](/documentation/contexts.html) and labels to mark which changeSets contain test data so they are not deployed to production.
-
-### Sanity checks
-
-Liquibase ships with several tools QA teams can use to: check current database state, make sure changes are being applied correctly and ensure that no one is sneaking-in changes out of process.
-
-- The status and validate commands report on what changeSets have not yet been run and checks the changelog for errors.
-- The [diff](/documentation/diff.html) command reports on differences between databases to ensure that two fully updated databases are truly identical
-- The [dbdoc](/documentation/dbdoc.html) command generates documentation on the current database structure and its changes over time
-
-### Enterprise features with Datical
-
-If your QA team finds their requirements extend beyond all these great capabilities check out Datical. Datical builds upon Liquibase and lets test teams:
-
-- Simulate or rehearse database deployments to [forecast potential errors](http://www.datical.com/product/packaging-intelligence/)
-- [Know the development status](http://www.datical.com/product/management-intelligence/) of every schema in the database
-- Automate database [change validation](http://www.datical.com/product/validation-intelligence/)
-
-More information on Datical DB can be [found here](http://www.datical.com/product-information/).
-
-
diff --git a/_posts/2016-05-10-liquibase-for-release-managers.md b/_posts/2016-05-10-liquibase-for-release-managers.md
deleted file mode 100644
index 283ea5e46..000000000
--- a/_posts/2016-05-10-liquibase-for-release-managers.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase for Application Release Managers
----
-# Liquibase for Application Reelase Managers
-
-In the modern agile development environment there is a lot that happens in a very short period of time. This means application release managers need to be efficient with their time while ensuring nothing falls through the cracks. The database updates that go along with each application release are just as important as the application code, both for deployment and for planning rollbacks.
-
-By adopting Liquibase, application release managers are able to know that the database change scripts Developers write, QA teams test, and the DBAs sign-off on will be automatically and consistently checked and validated every time a new release is ready to push to production. In addition, Liquibase makes database rollback easy.
-
-### Prepare for deployment problems
-
-Releases don't always go as planned, and Liquibase helps application release managers ensure contingency plans are correct before each release. As teams get closer to releasing new application updates, besides checking the updateSql output, release managers can also run [futureRollbackSql](http://www.liquibase.org/documentation/rollback.html) which will output the SQL needed to bring a fully updated database back to the current state.
-
-### No change is forgotten
-
-Liquibase [tracks which changelog statements](http://www.liquibase.org/documentation/databasechangelog.html) have run against each database, so release managers no longer have to manually track what statements have been run against each database and which have not.
-
-### Sanity checks
-Liquibase ships with several tools application release managers can use to: check current database state, make sure database changes are being applied correctly and ensure that no one is sneaking in changes out of process.
-
-- The status and validate commands report on what changeSets have not yet been executed and checks the changelog for errors.
-- The [diff](http://www.liquibase.org/documentation/diff.html) command reports on differences between databases to ensure that two fully updated databases are truly identical
-- The [dbdoc](http://www.liquibase.org/documentation/dbdoc.html) command generates documentation on the current database structure and its changes over time
-
-### Enterprise features with Datical
-
-If your application release teams determine their needs extend beyond all the great capabilities Liquibase offers check out Datical. Datical builds upon Liquibase and lets release managers:
-
-- Automate SQL reviews against business rules
-- Simulate or rehearse deployments to forecast potential errors
-
-Know the development status of every schema in the database
-
-More information on Datical can be found [here](https://www.datical.com/).
-
diff --git a/_posts/2016-05-11-liquibase-3-5-1-released.md b/_posts/2016-05-11-liquibase-3-5-1-released.md
deleted file mode 100644
index 6137b5d1d..000000000
--- a/_posts/2016-05-11-liquibase-3-5-1-released.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.5.1 Released
----
-# Liquibase 3.5.1 Released
-
-Bugfix release Liquibase 3.5.1 is now available from [liquibase.org/download](/download) and through the Maven repositories.
-
-### Fixes include:
-
-- Fixed handling of Liquibase running inside a nested jar (like in Spring Boot)
-- NullPointerException in diff command
-- Fixes to whitespace handling and checksums in loadData
-
-### Full changelog:
-
-- [CORE-2727] - NPE in DiffToReport.print() method
-- [CORE-2728] - Classloading broken in 3.5.0 with nested jars
-- [CORE-2729] - NullPointerException on Diff
-- [CORE-2731] - diff fails with NullPointerException
-- [CORE-2732] - releaseLock fails because ObjectQuotingStrategy is reset to LEGACY
-- [CORE-2733] - relativeToChangelogFile fails with FileSystemResourceAccessor
-- [CORE-2734] - Liquibase no longer handle newline correctly in endDelimiter when using sqlFile change
-- [CORE-2743] - CSV whitespace trimmed in 3.5.0
-- [CORE-2744] - changeset with loadUpdateData changes checksum in 3.5.0
-- [CORE-2745] - Performance degradation of sqlFile change
-- [CORE-2746] - Oracle: handle case when schema name contains a hyphen
-- [CORE-2750] - MSSQL catalog/database included all the time
\ No newline at end of file
diff --git a/_posts/2016-05-19-liquibase-for-developers.md b/_posts/2016-05-19-liquibase-for-developers.md
deleted file mode 100644
index 0e85ed4ef..000000000
--- a/_posts/2016-05-19-liquibase-for-developers.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase for Application Developers
----
-# Liquibase for Application Developers
-
-Agile development practices and modern source control systems such as Git have transformed how application software is developed and managed.
-
-But for many application developers the way the database is changed is the same as it was in 1995.
-Well, maybe not exactly the same—now SQL files for each release are stored in a shared Windows drive instead of a shared Novell server – but you catch my drift.
-
-### Store database changes along side application code
-
-The database schema is an integral part of any application, so changelog files should be stored along side application code. That will allow an existing version control system to ensure everything is kept in sync--whenever application code is committed database changes will go along with it and whenever anyone updates application code they will get the new database schema.
-
-### Supports branches
-
-Branches are an integral part of developing application code and database changes need to flow along with them. Because Liquibase tracks each changeSet independently rather than relying on a single incrementing "database version", when application developers merge in a branch all the new changeSets will execute as expected, even if there were "later" changeSets already executed.
-
-When developers do run into merge issues, the simple text formats used for the changelog files can be easily merged with their favorite tools.
-
-### Author changeSets in your favorite markup
-
-Liquibase supports changelogs written in XML, YAML, JSON and SQL. Use whatever is most readable to you.
-
-### Know that changes will not get forgotten down the line
-
-Liquibase [tracks which changelog statements](http://www.liquibase.org/documentation/databasechangelog.html) have run against each database, so once developers create a changeSet they can be confident that it will be deployed through QA and production.
-
-For best results, whenever an application developer need a database change, they can simply append a new changeSet to the local database and then run a Liquibase update to apply it. This works better than making changes to a database directly and re-writing it as a changeSet because they are truly running the same update as everyone else.
-
-### Like SQL? Use SQL.
-
-XML-formatted changelogs have their advantages, but many DBAs still prefer good, old-fashioned SQL. If that is what you are most comfortable working with, [Liquibase-formatted SQL](http://www.liquibase.org/documentation/sql_format.html) provides the standard changeSet tracking used in any changelog format but lets the DBA specify the exact SQL they want.
-
-### Easier test data management
-
-Normally, test data is stored in something like CSV files which are loaded into the database after it is built. The problem with this strategy is that any schema changes can and will break something in the data load process. Typically this leads to application development teams spending hours of time trying to figure out what the test data was trying to expose and then adjusting the files to match the new schema.
-
-Instead of loading the data into the final schema, build up the test data within a changelog file. Use [loadData](http://www.liquibase.org/documentation/changes/load_data.html) or standard [sql](http://www.liquibase.org/documentation/changes/sql.html) to load data into the schema as it is now, then as new schema changes are appended to the changelog the test data will be migrated just like production data would be. This not only keeps application developers from having to continually update your CSV files, but also helps verify that existing data is handled correctly.
-
-Another best practice is to use [contexts](http://www.liquibase.org/documentation/contexts.html) and labels to mark which changeSets contain test data so they are not deployed to production.
-
-### Sanity checks
-
-Liquibase ships with several tools application development teams can use to: check current database state, make sure changes are being applied correctly and ensure that no one is sneaking in changes out of process.
-
-- The status and validate commands report on what changeSets have not yet been run and checks the changelog for errors.
-- The [diff](http://www.liquibase.org/documentation/diff.html) command reports on differences between databases to ensure that two fully updated databases are truly identical
-- The [dbdoc](http://www.liquibase.org/documentation/dbdoc.html) command generates documentation on the current database structure and its changes over time
-
-### Enterprise features with Datical
-
-If your application development team determines their needs extend beyond all the great capabilities Liquibase offers check out Datical. Datical builds upon Liquibase and lets DBAs:
-
-- [Package database schema changes](https://www.datical.com/solution/database-code-packager/) alongside application code
-- Simulate or rehearse database deployments to [forecast potential errors](https://www.datical.com/solution/change-management-simulator/)
-- [Know the deployment status](https://www.datical.com/solution/deployment-monitoring-console/) of every schema in the database
-- Integrate with popular [DevOps tools](https://www.datical.com/integrations/)
-
-More information on Datical DB can be [found here](https://www.datical.com/).
-
diff --git a/_posts/2016-06-01-liquibase-for-dba.md b/_posts/2016-06-01-liquibase-for-dba.md
deleted file mode 100644
index e08a951c3..000000000
--- a/_posts/2016-06-01-liquibase-for-dba.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase for DBAs
----
-# Liquibase for DBAs
-
-The role of the Database Administrator is evolving and has never been more complex. DBA's are constantly juggling schema management, performance tuning, change control, plus database administration all within ever-shortening application development cycles. On top of all that, there are more database environments to manage than ever before, more distributed sources of database changes, and more stringent compliance requirements.
-
-It is easy for database changes to get lost or misapplied along the way and far too often the place where problems are found is in production. Fortunately, Liquibase can bring a sense of control to the database deployment process while still giving DBAs the control they need. In addition Liquibase works alongside the database professionals preferred toolset.
-
-### No change is forgotten
-
-Liquibase [tracks which changelog statements](http://www.liquibase.org/documentation/databasechangelog.html) have run against each database, so DBAs no longer have to manually track which SQL statements have been run and which have not.
-
-### Like SQL? Use SQL
-
-XML-formatted changelogs have their advantages, but many DBAs still prefer good old fashioned SQL. If that is what the team is most comfortable working with, [Liquibase-formatted SQL](http://www.liquibase.org/documentation/sql_format.html) provides the standard changeSet tracking used in any changelog format, but lets the DBA specify the exact SQL you want.
-
-### Manually verify the database changes with each release
-
-Liquibase supports an "[updateSql](http://www.liquibase.org/documentation/sql_output.html)" command that will not actually update the database, but instead output the SQL that will run. That script can be read and verified to ensure everything is correct and performing as expected.
-
-Once everything is correct, DBAs can either run a Liquibase update, or run the script through their favorite tools. The script will include the [DATABASECHANGELOG](http://www.liquibase.org/documentation/databasechangelog_table.html) inserts so everything will still be correctly tracked.
-
-### Prepare for deployment problems
-
-Releases don't always go as planned, so Liquibase ensures contingency plans are correct before each release. As teams get closer to releasing new application updates, besides checking the updateSql output, DBAs can also run [futureRollbackSql](http://www.liquibase.org/documentation/rollback.html) which will output the SQL needed to bring a fully updated database back to the current state. It will be much less stressful verifying the rollback logic BEFORE the release.
-
-### A unified changelog for all your databases
-
-DBAs try to keep all databases the same, but there are always differences. QA needs test data, production gets a couple extra tables, and the hot-backup server needs extra configuration. Liquibase supports contexts, labels, parameters, and preconditions that let database professionals address minor differences in scripts to adjust things as needed.
-
-- [Contexts](http://www.liquibase.org/documentation/contexts.html) and labels target certain changeSets to run in only some environments.
-- [Parameters](http://www.liquibase.org/documentation/changelog_parameters.html) perform simple text substitutions when things like schema names vary from database to database.
-- [Preconditions](http://www.liquibase.org/documentation/preconditions.html) check the state of the database to dynamically determine if a changeSet should be executed or not.
-
-Thanks to Liquibase's [cross-database support](http://www.liquibase.org/databases.html), DBAs can even use a single changelog that supports Oracle, MS SqlServer, Postgresql, and more.
-
-### Enterprise features with Datical
-
-If your DBAs determine their needs extend beyond all the great capabilities Liquibase offers check out Datical. Datical builds upon Liquibase and lets DBAs:
-
-- [Package database schema changes](http://www.datical.com/product/packaging-intelligence/) alongside application code
-- Simulate or rehearse database deployments to [forecast potential errors](http://www.datical.com/product/validation-intelligence/)
-- [Know the deployment status](http://www.datical.com/product/management-intelligence/) of every schema in the database
-- Integrate with popular [DevOps tools](http://www.datical.com/integrations/)
-
-More information on Datical DB can be [found here](http://www.datical.com/product-information/).
-
-
diff --git a/_posts/2016-06-16-happy-birthday-liquibase.md b/_posts/2016-06-16-happy-birthday-liquibase.md
deleted file mode 100644
index 00b694772..000000000
--- a/_posts/2016-06-16-happy-birthday-liquibase.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Happy Birthday! 10 Years of Liquibase
----
-# Happy birthday to Liquibase
-
-10 years ago today was the [initial public announcement of Liquibase, originally called the "Sundog Database Refactoring Tool"](http://www.theserverside.com/news/thread.tss?thread_id=40959).
-
-Like most open source projects, Liquibase started out simply as a tool to solve a problem I had. We had many different client projects on a variety of databases and it was getting more and more difficult to ensure that changes everyone made in development reached other developers and production. I was primarily using Java at the time and was not able to find anything that would solve our needs. There were tools like Apache ddlutils but it did not track changes, it only kept the current state. There was also Rails Active Record Migrations, but that was Ruby and I didn't like the fact that their change tracking would not work across multiple branches and multiple developers. Not finding anything that worked, I started my own open source project.
-
-You can still see my initial requirements in Liquibase:
-
-- I needed to support multiple databases types, even the same code running against different database types
-- I needed a way to pull in blocks of database structure when I would pull in a shared library of functionality
-- I needed to support multiple developers and multiple branches under concurrent development
-- I needed a way to safely push updates to the database schema along with updates to the code without worrying about losing data or missing changes
-- I needed a way to store database changes along with the source code in our source control system
-
-Leading up to this point I had read [Ambler and Sadalage's book "Refactoring Databases: Evolutionary Database Design"](http://martinfowler.com/books/refactoringDatabases.html) which helped with envisioning database changes as a series of refactorings and inspired many of the higher-level refactoring tags like "addLookupTable"
-
-We've come a long way in 10 years. When Liquibase was first released, there was
-
-- The changelog XML file with its changeSets and change tags
-- ChangeSets were tracked by id + author + path
-- Support for
-- A command line, Ant, and servlet listener interface
-- Support for Java 1.4 and 1.5
-- Support for MySQL 4.1./5.0, Postgresql 8.1, Oracle 10gR2, and MS SqlServer 2005
-
-Since that initial release we've had almost 70 releases with help from innumerable contributors. We've added support for more databases, more changelog file formats, preconditions, tagging, contexts, dbdoc, changelog parameters, diff, offline database support, and much, much more. Plus, we came up with a better name--even if it was [poorly capitalized initially.](http://www.liquibase.org/2010/07/lower-case-b.html)
-
-What does the next 10 years have in store? Lots more of the same. Backwards compatibility has always been important to me and it is fun to see that the example changelog in the initial release can still be run with Liquibase 3.5.2. We are continuing to add support for new databases (including NoSQL databases), new refactoring's, and new features. The "Refactoring GUI IDE" mentioned in the initial announcement turned out to be well beyond the scope of what I could manage, has been realized in [Datical DB](http://www.datical.com/product/). I mentioned support for .Net in the initial announcement and I've not given up hope on that project yet, despite not making any progress on it so far. Javascript is another technology that could use a Liquibase port, if there are any volunteers...
-
-Since starting with Datical 3 years ago, I've not only had a business card that says "Benevolent Dictator for Life, Liquibase" but I've been able to work on Liquibase full time which has been invaluable in continuing to grow the project and help the community. Currently I am continuing to improve the 3.x codebase while starting a larger reworking of the code for a 4.0 release which will set us up for expanded functionality and simpler maintenance in the next decade. Also in the pipeline is website and documentation improvements, a better plugin portal, and much more.
-
-Because we are an open source project and don't really have "customers" it is impossible to know how many people use Liquibase, but there are thousands of visitors to [liquibase.org](http://liquibase.org) every day from almost every country on the planet. Liquibase has grown far more than I ever imagined when I started it as a fun side project a decade ago. I released it as an open source project because I wanted a chance to contribute back to the community and to see what it was like on the other side of an open source project. I've always been a believer in open source, and managing Liquibase has only solidified that belief because Liquibase could not be what it is today without the community around it.
-
-**THANK YOU ALL!**
diff --git a/_posts/2016-07-12-expanding-database-support.md b/_posts/2016-07-12-expanding-database-support.md
deleted file mode 100644
index 42cb63ea9..000000000
--- a/_posts/2016-07-12-expanding-database-support.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Expanding Database Support
----
-# Expanding Database Support
-
-Liquibase has always focused mainly on "standard" SQL databases, but we are looking to improving support for NoSQL databases like Cassandra, MongoDB, Hadoop and others.
-
-We'd also like to make sure our support for databases like DB2 on iSeries and System z as well as Redshift, Azure SQL Server, Vertica, Greenplumb etc.
-
-Unfortunately, I don't have a lot of experience with what is really needed to manage data and schemas on any of these databases and/or the particular pain points that need to be solved for each.
-
-If **YOU** have experience with any of these databases, we'd love to do a quick phone questionnaire about what you currently use, your ideal workflow, and a bit about your team and application size.
-Just send me an email at [nathan@liquibase.org](nathan@liquibase.org) and let me know where you are located so we can coordinate a convenient time for everyone.
-
-Thanks!
\ No newline at end of file
diff --git a/_posts/2016-08-31-indicators-ready-to-move-from-liquibase-to-datical.md b/_posts/2016-08-31-indicators-ready-to-move-from-liquibase-to-datical.md
deleted file mode 100644
index 698f2a582..000000000
--- a/_posts/2016-08-31-indicators-ready-to-move-from-liquibase-to-datical.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Top 5 Indicators You Are Ready to Move from Liquibase to Datical
----
-# Top 5 Indicators You Are Ready to Move from Liquibase to Datical
-
-Ten years ago, I started Liquibase to bring sanity to my database schema changes. At the time, I was working on a 3-tier Java web project. Ruby on Rails had Active Record Migrations and I asked, "Why can't I have that for Java?" Since then, Liquibase has become the standard for database change management. We support 13 databases and have 24 extensions for other databases. (Hi, Teradata and Hana!!!) All of that progress is because of our amazing users, committers, and testers. We couldn't have done it without you.
-
-A little over three years ago, I began working at [Datical](https://www.datical.com) to bring functionality to Liquibase that just didn't fit into our project goals. (Also, I really wanted to work full-time on my favorite OSS project!) More often than not, we see our biggest Datical advocates discover Datical DB after using Liquibase. I wanted to share some common themes I've seen when Liquibase users start using Datical DB.
-
-Before that, I wanted to be clear on how we view Liquibase's role in software development. Simply put: we solve one problem very well. Cross platform database change management is what Liquibase does. Much like Apache, we provide an API for users to extend Liquibase. That's what Datical has done with Liquibase; they have created extensions that extend and enhance Liquibase. It's these Datical extensions, user-interface, and integrations that may be useful to Liquibase users.
-
-### Your Team is Large
-
-In 2013 and 2015, I did a survey of our current Liquibase users. A large percentage (72%) of the 2015 respondents worked in companies where IT is less than 100. In my experience, Developers typically bring in Liquibase for a specific application. Then, usage of Liquibase starts to grow. One project, two, five...congratulations! You're moving faster than ever with database changes. Unfortunately, you're killing your DBAs.
-
-Most development teams will use Liquibase to help themselves manage database change. They then deliver SQL scripts for the DBAs to execute. While that works for the Development team, the speed at which changes are being produced is too much for the DBAs to consume.
-
-Two bits of functionality in [Datical](https://www.datical.com/solution/) help DBAs be more efficient than manually reviewing every SQL script. First, Datical DB provides Forecast functionality that details the impact of proposed database changes. Simply put, it's a "practice run" for your database changes. Secondly, that impact of those proposed changes is contained in HTML Reports. Thus, DBAs can quickly review the reports and understand the impact without having to inspect opaque SQL scripts.
-
-### The Distance Between Development and Production is High
-
-The closer you are to Development, your knowledge of the application increases. [QA](http://www.liquibase.org/2016/02/liquibase-for-qa.html) knows the application better than Production engineers, but less than Development. Conversely, the closer you are to Production, the more you know about the state of the Production systems. As the distance between these two groups increase, the difficulty in understanding the relationship between the database and application code changes. With a tightly integrated team, this is not a challenge. How often has a system administration walked over to your desk to answer a question? Now, imagine if Production support is in Asia while Development is in Europe. That's a long walk!
-
-Datical DB Forecast allows those performing the Production push to have a far greater understanding of the change impact. Moreover, they can run the Forecast at a time that's convenient for all stakeholders to get approval. This avoids late night surprises and the need to rollback. "What! There's a DROP TABLE in this script! WHY?!?!?"
-
-### You've Bought Other DevOps Tools
-
-I like to say that Liquibase was DevOps before DevOps was cool. Thankfully, more and more companies are adopting tools that support DevOps to enable continuous delivery through the software lifecycle. So, if you have the Liquibase plugin for Jenkins, you're well on your way. However, like all open source software, some assembly is required. Datical DB provides supported (and Open Source) plugins for all of your favorite [DevOps tools](http://www.datical.com/integrations/).
-
-### You Want to be Even Faster
-
-At some point with Liquibase, you will reach a point where Liquibase can no longer provide any improvements to the speed of your releases. Because Liquibase focuses on cross platform database change, a large number of platform specific objects are not supported directly by Liquibase. For example, for CHECK CONSTRAINTs in MySQL, you will simply have to include a SQL script to create that object. Datical DB includes vendor specific objects (like MSSQL Functions). Thus, implementing on legacy projects that use these objects is far easier with Datical DB.
-
-### You Worry About Compliance
-
-My favorite feature in Datical DB is the [Rules Engine](https://www.datical.com/solution/dynamic-rules-engine/). Thus, enforcing best practices is a snap. For example, let's say SOX compliance requires you to have a valid ServiceNow ticket. No problem. Datical DB can look at your Change Set and make sure a ticket number is included in the Change Set ID, if that's your standard. Or, imaging you are DBA with a pet peeve about new columns created with a default value set. Datical DB will actual fail a build if a proposed change violates a rule. This makes enforcing your regulatory and technical rules a breeze. With Liquibase, you would have to review each change or SQL script generated.
-
-So, if these issues aren't a concern for you, then keep using Liquibase! I'll still be here to fix bugs, add features, and merge in your pull requests. But, if you're ready to see how far you can go with database change management, come over here to get some more information about Datical DB.
-
-
-
diff --git a/_posts/2016-09-21-liquibase-3-5-2-released.md b/_posts/2016-09-21-liquibase-3-5-2-released.md
deleted file mode 100644
index 8ef35c9d8..000000000
--- a/_posts/2016-09-21-liquibase-3-5-2-released.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.5.2 Released
----
-# Liquibase 3.5.2 Released
-
-Bugfix release Liquibase 3.5.2 is now available from [liquibase.org/download](/download) and through the Maven repositories.
-
-### Highlights include:
-
-- Formatted SQL added rollbackSplitStatements and rollbackEndDelimiter changeSet attributes
-- Fixes for running in Spring boot 1.4.0
-- Performance improvements
-- More consistent use of the character encoding set with the liquibase.file.encoding system property
-- Improvements in support for clustered primary keys
-- Improved BINARY data type handling
-- Upgraded to SnakeYAML 1.17
-
-### Full changelog:
-
-- [CORE-1863] - PostgreSQL blob is mapped to bytea instead of oid
-- [CORE-2693] - Postgresql dropAll with serial columns fails because tables are dropped then sequences which no longer exist
-- [CORE-2698] - Oracle scripts with ending / are not actually getting executed even with splitStatements="false"
-- [CORE-2752] - Jtds has silent exceptions in db.getConnectionSchemaName
-- [CORE-2753] - defaultValueSequenceNext forgets schema name
-- [CORE-2754] - update table columns are not quoted when requested
-- [CORE-2756] - Null pointer exception from FileSystemResourceAccessor
-- [CORE-2757] - Databasechangelog ORDEREXECUTED and DEPLOYMENT_ID not updated when a changeSet is reran
-- [CORE-2758] - Debian package shouldn't symlink liquibase binary to absolute path
-- [CORE-2761] - 3.5.1: includeAll from the command line uses the absolute path as the changeSet path
-- [CORE-2763] - Postgresql schemas should default to lower case
-- [CORE-2765] - dbms in preConditions yaml changelog causes parsing error
-- [CORE-2770] - Can't read remarks from mssql 2000
-- [CORE-2774] - Can't read all columns from mssql2000
-- [CORE-2775] - Oracle Sequences not Generated in generateChangeLog after 3.4.1
-- [CORE-2778] - Sybase ASE: Incorrect syntax near the keyword 'ALTER'
-- [CORE-2780] - java.sql.SQLException: PooledConnection has already been closed
-- [CORE-2781] - DB2: custom-generated indexes for primary keys are not preserved in diff/generateChangeLog
-- [CORE-2784] - REGRESSION: Column creation of type 'TIMESTAMP WITHOUT TIMEZONE' fails on PostgreSQL
-- [CORE-2785] - Status command inconsistent with databasechangelog table
-- [CORE-2786] - Incorrect xml scheme for changlog file
-- [CORE-2787] - YAML Snapshot parser not handling strings that get stored as binary
-- [CORE-2789] - Postgres does not have a type "BINARY"
-- [CORE-2791] - Strip off trailing end delimiter in createProcedure on update, include on updateSql
-- [CORE-2793] - using property as startWith attribute
-- [CORE-2794] - Make CSV files created by Liquibase readable by Liquibase
-- [CORE-2795] - Fix a NullPointerException in DiffToChangeLog.sortMissingObjects
-- [CORE-2804] - defaultValueSequenceNext forgets schema name H2/PG/etc
-- [CORE-2805] - Multiple calls to generateChecksum() impacting deploy performance
-- [CORE-2806] - JsonSnapshotParser does not close stream after parsing
-- [CORE-2807] - Column data type "real" incorrectly translated to "double precision" for PostgreSQL, should be "real"
-- [CORE-2810] - defaultValueBoolean="false" generates wrong SQL for MySQL
-- [CORE-2811] - FileSystemResourceAccessor basepath/includeAll
-- [CORE-2813] - java.lang.NullPointerException when creating new ClassLoaderResourceAccessor();
-- [CORE-2814] - DB2: Quoting strategy not respected, objects are always saved as upper case
-- [CORE-2815] - Rollback by tag doesn't roll back tagDatabase changeSet
-- [CORE-2816] - Snapshot error when snapshotting an index or primary key against a case-sensitive column
-- [CORE-2818] - DEPLOYMENT_ID not created for Sybase in DATABASECHANGELOG, liquibase 3.5.1
-- [CORE-2819] - AbstractJdbcData getConnectionSchemaName() methods fails for Sybase
-- [CORE-2823] - DROP PRIMARY KEY fails for Sybase database update
-- [CORE-2827] - MSSQL: misc default value fixes
-- [CORE-2828] - MSSQL not capturing that primary key are non-clustered in generateChangeLog
-- [CORE-2830] - GenerateChangeLog does not handle tables with compound primary keys
-- [CORE-2831] - MySql BIT(1) defaultValue not snapshotted as Boolean
-- [CORE-2835] - GenerateChangeLog doesn't correctly "numeric DEFAULT '" " columns
-- [CORE-2836] - addAutoIncrement generates inconsistent sequence name for mixed-case table
-- [CORE-2837] - addAutoIncrement doesn't apply default schema in nextval call (PostgreSQL)
-- [CORE-2838] - createProcedure schema in the changelog is overwritten by defaultSchemaName
-- [CORE-2840] - MSSQL createProcedure for CREATE MERGE AS procedures need a trailing semicolon
-- [CORE-2843] - Sql wrong lexical analysis for string literals - escaped single quotes are misparsed
-- [CORE-2846] - DATABASECHANGELOG table query failed on postgres on first run
-- [CORE-2849] - Fail to execute with sequences
-- [CORE-2853] - Diff comparisions reporting differences between '0.0' and '0' in decimals
-- [CORE-2863] - Issue with Spring boot 1.4.0
-- [CORE-2864] - Regression for defaultSchemaName on MSSQL
-- [CORE-2867] - liquibase with MySQL raises exception "Table 'DATABASECHANGELOG' already exists" when using separate liquibase schema
-- [CORE-2868] - Adds schema/username to package and package body in oracle making them invalid
-- [CORE-2869] - Without a specified classpath, using includeAll with relativeToChangelogFile="true" fails
-- [CORE-2872] - "ON DELETE" not supported for FK constraints in Sybase
-- [CORE-2876] - Issue with Spring boot 1.4.0 Repackaged
-- [CORE-2878] - MSSQL setTableRemarks limited to 200 chars
-- [CORE-2881] - DiffChangeLog unnecessarily includes referenceTableCatalogName attribute if comparing Schema with different names
-- [CORE-2885] - AddColumn with defaultValueSequenceNext generated incorrect SQL for PostgreSQL
-- [CORE-2788] - handle VARBINARY type in Oracle and H2
-- [CORE-2800] - Add flag to diff command that suppresses reporting of column order difference in tables
-- [CORE-1984] - Support for non-split rollback statements in Formatted SQL
-- [CORE-2768] - Have the .deb and .rpm part of the release on github
-- [CORE-2782] - Update SnakeYAML version to 1.17
-- [CORE-2801] - Add method to Logger to allow closing of the output file stream
-- [CORE-2844] - Traverse parent changelogs for rollbacks
-- [CORE-2848] - Oracle: primary keys that use a pre-existing index drop the index along with the primary key on rollback
-- [CORE-2852] - Postgresql snapshots not correctly handling serial-backing sequences
-- [CORE-2857] - Support clustered primary keys in postgresql
-- [CORE-2873] - Postgresql custom types are snapshotted as having length 2147483647
-- [CORE-2874] - Ensure consistent charset encoding usage
-
-[Issue Tracker](https://liquibase.jira.com/secure/ReleaseNote.jspa?projectId=10020&version=13260)
-
diff --git a/_posts/2016-10-13-liquibase-3-5-3-released.md b/_posts/2016-10-13-liquibase-3-5-3-released.md
deleted file mode 100644
index 0f53b7a30..000000000
--- a/_posts/2016-10-13-liquibase-3-5-3-released.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.5.3 Released
----
-# Liquibase 3.5.3 Released
-
-The issue that caused me to pull the 3.5.2 release turned out to be a false alarm.
-
-Therefore, Liquibase 3.5.3 is now available from [liquibase.org/download](http://liquibase.org/download) and through the Maven repositories with no changes vs 3.5.2 besides a new version number.
-
-Sorry for any inconvenience or concern.
\ No newline at end of file
diff --git a/_posts/2016-10-24-liquibase-hibernate-3.6-released.md b/_posts/2016-10-24-liquibase-hibernate-3.6-released.md
deleted file mode 100644
index ca84aba34..000000000
--- a/_posts/2016-10-24-liquibase-hibernate-3.6-released.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase-Hibernate Plugin 3.6 Released
----
-# Liquibase Hibernate Plugin 3.6 Released
-
-After far too long, the Liquibase-Hibernate plugin has been updated to **support Hibernate 5.x!!**
-
-To use the new Hibernate 5 support, either download the liquibase-hibernate5 jar from the [release page](https://github.com/liquibase/liquibase-hibernate/releases)
-or change your maven coordinates to <artifactId>liquibase-hibernate5</artifactId> instead of <artifactId>liquibase-hibernate4</artifactId>.
-
-I have also released a 3.6 version of the liquibase-hibernate4 plugin that fixes some issues and also supports the newest Liquibase 3.5.3.
-
-### Potential Issues
-
-Because of changes in how Hibernate handles its naming between 4.x and 5.x, you now need to use separate implicitNamingStrategy and physicalNamingStrategy settings.
-The Liquibase-Hibernate plugin will try to pick these up from your configuration automatically, but if you are setting them in your liquibase "url" you may need to change them.
-
-Liquibase 3.5 introduced a change to how the the loadData change computed checksums of the CSV. The fix made it more forgiving of whitespace added to the file, but if you
-previously had whitespace in your csv file you will get checksum validation errors. Adding the <validCheckSum>*</validCheckSum> tag to any problem changeSets will fix the problem.
-
-### Additional changes in this release
-
-- Better diffChangeLog/generateChangeLog support for unique constraints
-- Improved support for @Clob and @Lob annotations
-- Improved detection and use of hibernate dialects
-- Improved handling of indexes and primary keys
-
-The full changelog is available at [https://github.com/liquibase/liquibase-hibernate/milestone/6?closed=1](https://github.com/liquibase/liquibase-hibernate/milestone/6?closed=1)
-
-Any issues or feature suggestions can be added to [https://github.com/liquibase/liquibase-hibernate/issues](https://github.com/liquibase/liquibase-hibernate/issues)
\ No newline at end of file
diff --git a/_posts/2016-4-21-liquibase-3-5-0-released.md b/_posts/2016-4-21-liquibase-3-5-0-released.md
deleted file mode 100644
index 7ee51c546..000000000
--- a/_posts/2016-4-21-liquibase-3-5-0-released.md
+++ /dev/null
@@ -1,206 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.5.0 Released
----
-# Liquibase 3.5.0 Released
-
-Liquibase 3.5.0 is now available from [liquibase.org/download](http://liquibase.org/download) and through the Maven repositories. Question or comments can be directed [to liquibase.org/community](http://liquibase.org/community)
-
-There has been a lot of work put into 3.5.0, including:
-
-### Multi-schema snapshot and diff improvements
-
-We have fixed up various bugs with how Liquibase handles snapshotting and comparing multiple schemas.
-
-Beyond just bugfixes, you can also now specify mappings between source and target database schemas by using a new --referenceSchemas flag. I'll write more about this feature in a future blog post.
-
-### OSGi support in liquibase-core
-
-You no longer need to use the liquibase-osgi jar when running in an OSGi container. The standard liquibase.jar / liquibase-core module is all you need.
-
-### New "context" attribute on include and includeAll to control when changelogs are included
-
-If you specify the "context" attribute on include or includeAll, the referenced changelog files will only be executed if you are running under a matching context.
-
-### Formatted SQL changelog improvements
-
-We brought in some features from XML and YAML style changelogs to [formatted sql](http://liquibase.org/documentation/sql_format.html) including support for AND/OR context expressions and [changelog parameters](http://liquibase.org/documentation/changelog_parameters.html).
-
-### New runOrder="first|last" attribute on changeSet to override where in the changelog it is ran
-
-Sometimes you want a changeSet to always execute after everything else but don't want to keep moving it to the end of the changelog. Setting the runOrder will automatically move it in the final changeSet order.
-
-### Improved SQL Parsing
-
-Instead of using regular expressions to try to parse SQL, we now tokenize it using a grammer. This will make SQL parsing much less buggy and fixes a large set of bugs.
-
-### Performance improvements and bug fixes
-
-Always performance improvements and bug fixes
-
-### Full Release Notes
-
-Thanks to everyone who helped with [all these issues](https://liquibase.jira.com/secure/ReleaseNote.jspa?projectId=10020&version=12560)
-
-
-- [CORE-155] - Default-context attribute in databaseChangeLog tag
-- [CORE-575] - foreign key constraint is generated with onUpdate and onDelete restrict
-- [CORE-910] - Lock is not released if nocount is on for sql server 2008
-- [CORE-1166] - Diff doesn't detect 'on delete cascade' statements
-- [CORE-1447] - Inconsistent line endings in updateSQL produced files
-- [CORE-1468] - Number / Numeric handling must differ between different database systems
-- [CORE-1679] - Changelog SQL routines are partially aware of Database quoting strategy
-- [CORE-1690] - OSGiPackageScanClassResolver does not search extensions in Fragment bundles
-- [CORE-1836] - Oracle Integer mapping
-- [CORE-1839] - H2 multicolumn unique constraints
-- [CORE-1883] - Performance issue with large datamodels
-- [CORE-1887] - Including the same ChangeSet twice causes ValidationFailedException
-- [CORE-1897] - stripComments from SQL is trimming quoted string
-- [CORE-1935] - Formatted SQL generateChangeLog failed
-- [CORE-1966] - Invalid object name 'INFORMATION_SCHEMA.SEQUENCES' when running generateChangeLog with SQL Azure
-- [CORE-1985] - constraints tag is missing referencedTableSchemaName
-- [CORE-2024] - Move SDK to its own module
-- [CORE-2056] - generateChangeLog generates too many 'constraints'
-- [CORE-2059] - escapeObjectName has no respect for quotingStrategy QUOTE_ONLY_RESERVED_WORDS on Postgres
-- [CORE-2184] - diff doesn't write correct Changesets for foreign key constraints with ON DELETE CASCADE
-- [CORE-2211] - Liquibase tries to execute commented lines in custom SQL file
-- [CORE-2213] - Liquibase does not support comments in a line after the semicolon
-- [CORE-2333] - loadData fails with quoted string containing a comma
-- [CORE-2376] - LiquibaseCatalogName in commandLine not working correctly
-- [CORE-2438] - DeleteGenerator does not handle parameter names and values with $ or \ properly
-- [CORE-2456] - includeObjects/excludeObjects not work for UniqueConstraint
-- [CORE-2474] - dropFirst does not drop objects in not default schemas on Postgres 9+ using sql format with multiple schemas
-- [CORE-2483] - Liquibase does not delete unzip directories from temporary directory
-- [CORE-2501] - Derby sequenceCurrentValue Incorrect SQL
-- [CORE-2502] - Handle single-tag databaseChangeLog tag on diffChangeLog
-- [CORE-2504] - NumberFormatException while checking precondition
-- [CORE-2508] - GlobalConfiguration liquibase.should.run alias is incorrect
-- [CORE-2512] - Both defautValueComputed and defaultValue included in addColumn diffChangeLog outputs if value is a computed value
-- [CORE-2513] - DiffChangeLog fixing changed indexes misses "unique" attribute
-- [CORE-2514] - bad Maven documentation for outputDefaultCatalog and outputDefaultSchema
-- [CORE-2517] - Foreign key snapshot improvements for DB2
-- [CORE-2518] - DB2: snapshot sees DATE types as TIMESTAMP
-- [CORE-2520] - Spurious warning with includeAll: file is not a recognized file type
-- [CORE-2521] - addAutoIncrement on Postgres generates invalid SQL when specific schema is used
-- [CORE-2522] - Derby: support for findForeignKeyConstraints
-- [CORE-2523] - H2: use "REAL" as datatype for "FLOAT"
-- [CORE-2524] - MSSQL: need to escape default value constraint names
-- [CORE-2525] - Error on dropping sequence
-- [CORE-2526] - Oracle 12: TIMESTAMP(3) not handled
-- [CORE-2528] - Oracle: improve unique constraint snapshot query performance
-- [CORE-2529] - MSSQL auto_increment numeric is 1 smaller in generateChangeLog
-- [CORE-2531] - Wrong type mapping of BINARY type in MySQL, H2, HSQLDB and Postgresql
-- [CORE-2533] - Poor runtime performance
-- [CORE-2538] - regenerate maven documentation for liqubase on website
-- [CORE-2545] - MSSQL: createProcedure fails if replaceIfExists=true and body uses "create proc" rather than "create procedure"
-- [CORE-2547] - liquibase.database.core.DB2Database - Improper Resource Shutdown or Release
-- [CORE-2548] - primaryKeyTablespace is ignored in PostgreSQL
-- [CORE-2550] - Proper handling BINARY type in MySQL and H2
-- [CORE-2552] - Oracle performance: fetch view definition along with original view to reduce the number of needed queries
-- [CORE-2553] - DB2: add ability to disable automatic reorg statements
-- [CORE-2556] - Cannot execute update code including quoted strings containing semicolons
-- [CORE-2558] - includeAll incorrectly sorting by including WEB-INF/classes when running in an ear
-- [CORE-2561] - Add "cycle" attribute to alterSequence
-- [CORE-2562] - MSSQL: Snapshot errors if table names have single quote marks in them
-- [CORE-2563] - DiffChangeLog that adds columns does not preserve column order
-- [CORE-2565] - Escaping of the sequence names with schema generates invalid statements for Oracle DB
-- [CORE-2581] - mysql update emits incorrect sql for BIT(1) when default specified
-- [CORE-2587] - Validation not performed before rollback
-- [CORE-2591] - autoincrement problem with ORA 12c + COMPATIBLE param to 11
-- [CORE-2595] - DefaultPackageScanClassResolver fails if "fat" jar has dirs and files with same name
-- [CORE-2599] - generateChangelog produces incorrect values for binary type
-- [CORE-2601] - ORDER keyword isn't escaped for Oracle
-- [CORE-2602] - StackOverflowError generating snapshot
-- [CORE-2604] - PostgreSQL datatype bit(n) column gives BOOLEAN(n) type for CreateTableChange genearated sql statement
-- [CORE-2605] - addColumn with multiple columns, does not create the constraints
-- [CORE-2606] - PostgreSQL : Table creation with datatype smallserial fails.
-- [CORE-2609] - Liquibase command line fails when using JTDS driver with SSO
-- [CORE-2611] - Sybase ASE generated table name is wrong. Roll back CORE-2447
-- [CORE-2615] - Multi-schema snapshot bugfixes
-- [CORE-2623] - Oracle: primary keys on tables recovered from recyclebin are not properly snapshotted
-- [CORE-2624] - MSSQL: better support for user defined types
-- [CORE-2625] - Diff: should not be case sensitive in column default value functions
-- [CORE-2629] - SQL syntax doesn't allow commenting indepenrent parts.
-- [CORE-2632] - Postgres index drop needs schema
-- [CORE-2635] - Applied changeset not detected
-- [CORE-2636] - includeAll uses full file path
-- [CORE-2637] - Creating column with tinyint(1) instead created as default tinyint
-- [CORE-2641] - runOnChange change set runs every time even if there wasn't changed
-- [CORE-2642] - Xsd files are not resolved from classpath when resolving from resourceAccessor fails.
-- [CORE-2643] - loadData
-- [CORE-2645] - Rollback referencing a change set in current child file cannot be parsed
-- [CORE-2653] - Liquibase show difference for some UniqueConstraint and Views in SQL SERVER databases but Actually there is NO difference when i compare the SQL scripts manually
-- [CORE-2660] - Multiple contexts not recognized in formatted SQL when using AND
-- [CORE-2662] - NumberFormatException with default values of type 'real' in postgresql
-- [CORE-2663] - New MySQL 5.7.x reserved keywords are not being escaped
-- [CORE-2664] - createChangeLog has incorrect nesting of constraints in YAML format
-- [CORE-2666] - InsertSetGenerator hard-codes the InsertGenerator
-- [CORE-2669] - Impossible to extend BaseLiquibaseTask in a non-deprecated way
-- [CORE-2670] - Impossible to create table on mssql with remarks containing apostrophes
-- [CORE-2671] - oracle timestamps with time zone
-- [CORE-2672] - createSequence with order produces invalid statement on postgresql
-- [CORE-2673] - includeAll relativeToChangelogFile doesn't work for FileSystemResourceAccessor
-- [CORE-2674] - LoadUpdateData with onlyUpdate="true" generates invalid statements for Oracle DB
-- [CORE-2677] - Dropping a postgres index fails
-- [CORE-2679] - Hibernate diffChangeLog NullPointerException @ MissingPrimaryKeyChangeGenerator.fixMissing(MissingPrimaryKeyChangeGenerator.java:76)
-- [CORE-2680] - Generating a futureRollbackSql when using "classpath:" prefix doesn't recognise any of the ran change sets.
-- [CORE-2681] - H2 (automatic mixed mode): createTable: columns remarks ignored
-- [CORE-2683] - dropAll dropping sequences that have been dropped via earlier cascade
-- [CORE-2684] - Context is ignored with runOnChange and including file (sqlFile/loadUpdateData)
-- [CORE-2686] - StandardChangeLogHistoryService.hasDatabaseChangeLogTable value is cached too aggressively
-- [CORE-2687] - sqlFile endDelimiter="go" if endDelimiter has whitespace in my sql it is not spliting
-- [CORE-2688] - Loading data from csv with number of rows dividable by 51
-- [CORE-2689] - TIMESTAMP parameters dropped for DB2
-- [CORE-2690] - SetTableRemarksGenerator double escapes remark
-- [CORE-2693] - Postgresql dropAll with serial columns fails because tables are dropped then sequences which no longer exist
-- [CORE-2694] - "national character varying" type is not recognized
-- [CORE-2698] - sqlFile Oracle scripts with ending / are not actually getting executed even with splitStatements="false"
-- [CORE-2699] - concurrency causes NullPointerException in DatabaseObjectComparatorFactory.getInstance()
-- [CORE-2705] - diffChangeLog generates dropColumn when dropping an index with a computed column
-- [CORE-2706] - Two sides of equal are the same
-- [CORE-2709] - endDelimiter regexp problem
-- [CORE-2711] - Cannot load CSV via loadData
-- [CORE-2713] - CreateView disregards replaceIfExists=true when fullDefinition=true
-- [CORE-2715] - tableExists and columnExists preconditions fail on MySQL
-- [CORE-2718] - H2 Database should query for default schema instead always use PUBLIC
-- [CORE-2719] - Oracle: Cannot snapshot primary keys on lower-case tables
-- [CORE-2720] - DB2: Capture full view definition in snapshot/generateChangeLog to support column options
-- [CORE-2721] - endDelimiter regex does not work in SQL changelogs/changesets
-- [CORE-2725] - DB2: Don't include system-generated indexes
-- [CORE-521] - Handle Timestamp with Time Zone types where supported
-- [CORE-2448] - New "created" attribute on changeSet
-- [CORE-2478] - Liquibase dropAll command line does not allow dropping multiple schemas
-- [CORE-2540] - Allow vendor independent SEQUENCE definition
-- [CORE-2541] - Add support for registering a Change Exec Listener on command line
-- [CORE-2560] - Add new runOrder="first\|last" attribute to control when a changeSet is ran
-- [CORE-2577] - Add resourceComparator attribute to includeAll to override sorting
-- [CORE-2578] - Added addUniqueConstraint deferrable"support for Postgresql
-- [CORE-449] - Same changeLog can be included multiple times
-- [CORE-1969] - Support for AND/OR context expressions in formatted sql
-- [CORE-2100] - formatted sql validCheckSum
-- [CORE-2115] - Really slow when using fat jars
-- [CORE-2225] - please add the OLD check sum to the validation error message
-- [CORE-2336] - Use a grammer for parsing SQL rather than regexps
-- [CORE-2419] - Support fluent/builder-style change properties
-- [CORE-2455] - Improve messages in databasechangelog.description column
-- [CORE-2463] - Don't include liquibase tables in dbdoc
-- [CORE-2493] - ExecuteShellCommand improvements
-- [CORE-2497] - Support setColumnRemarks and setTableRemarks on MSSQL
-- [CORE-2499] - Support for commenting lines in csv files
-- [CORE-2539] - Ensure each data row in CSV has same # cols as header
-- [CORE-2584] - ValidCheckSum is valid for both stored database values and current changeSet checksum
-- [CORE-2589] - Output xml changelogs as xml version="1.1"
-- [CORE-2612] - Oracle: include BYTE in CHAR and VARCHAR types from snapshot/generateChangeLog
-- [CORE-2619] - Make changeLogFile optional for changeSetExecuted
-- [CORE-2622] - Maven: Support ISO date syntax for rollback
-- [CORE-2626] - Use schemaName in createProcedure
-- [CORE-2638] - GenerateChangeLog should include replaceIfExists=true for changed views
-- [CORE-2640] - Better handling of replaceIfExists in createProcedure
-- [CORE-2651] - Derby: Default unknown version to 10.6 to support sequences
-- [CORE-2652] - Formatted sql precondition not expanding changelog parameters
-- [CORE-2657] - Add new DATABASECHANGELOG.DEPLOYMENT_ID column to track changeSets deployed together
-- [CORE-2658] - Move the liquibase-debian module to a separate profile
-- [CORE-2703] - MySQL NCLOB should conver to LONGTEXT CHARACTER SET utf8
-- [CORE-2724] - Support offline databases in ant-tasks
-
diff --git a/_posts/2018-03-14-liquibase-3-5-5-released.md b/_posts/2018-03-14-liquibase-3-5-5-released.md
deleted file mode 100644
index ae1c9c0c9..000000000
--- a/_posts/2018-03-14-liquibase-3-5-5-released.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.5.5 Released
----
-# Liquibase 3.5.5 Released
-
-For those of you not watching the download page every day, Liquibase 3.5.5 was released on Feb 15th.
-
-The 3.5.5 release is a bugfix release, pulling in a few high-prioritly/low impact changes in preparation for a larger 3.6.0 release in a few weeks.
-
-### Highlights include:
-
-- Fixed handling Java 9+ version numbers
-- Spring fixes
-- includeAll fixes
-
-I’m currently in final testing of the 3.6.0 release which includes over 1000 commits covering the last year of development so stay tuned for that.
-
-As promised, the new versions will continue to be released on a far more regular basis than over the last year so look forward to great things!
-
-### Download
-
-As always, the release is now available from [liquibase.org/download](/download) and through the Maven repositories.
-
-### 2018 Community Survey
-
-The 2018 Liquibase Community Survey is also now open. Please take 5 minutes to let us know [how you are using Liquibase and how we can improve it](https://goo.gl/forms/Atzmtw7XZatOehuP2). Thanks!
-
-### Full changelog:
-
-- [CORE-2851] - includeAll tag with a relative path duplicates the database changes with an absolute and with a relative changelog
-- [CORE-2863] - Issue with Spring boot 1.4.0 - 1.4.3
-- [CORE-2898] - includeAll broken in 3.5.1
-- [CORE-2948] - Changelog with includeAll will not find child changelogs in Spring Boot's executable JAR
-- [CORE-2978] - AddAutoIncrement on Postgres does not work when no schema is specified
-- [CORE-3123] - ResourceComparator is not applied for includeAll
-- [CORE-3139] - ClassLoaderResourceAccessor cannot read jar path resources from SpringLiquibase
-- [CORE-3015] - Oracle: diffChangeLog TIMESTAMP WITH LOCAL TIME ZONE correctly
-
-[Issue Tracker](https://liquibase.jira.com/secure/ReleaseNote.jspa?projectId=10020&version=13400)
-
diff --git a/_posts/2018-03-15-survey-2018.md b/_posts/2018-03-15-survey-2018.md
deleted file mode 100644
index 655a281bc..000000000
--- a/_posts/2018-03-15-survey-2018.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: 2018 Community Survey
----
-# 2018 Community Survey
-
-Listening to feedback from the community is a vital part of any open source project and it has frankly been a little too long since I’ve had the chance to hear the voice of those who make use of Liquibase.
-As I make more time to devote to the project, I’m keen to understand your perspective – if nothing else, to inform my priorities as I go through pull requests and think through additional updates.
-
-So, without further ado, I’d like to announce the [2018 Liquibase Community Survey!](https://goo.gl/forms/Atzmtw7XZatOehuP2)
-Please take 5 minutes to fill out the survey and give me your thoughts on the project, how you use it, and how we can continue to improve it.
-
-Lastly, a slightly shameless plug. In addition to founding and serving as the primary maintainer of Liquibase, my day is spent working on enterprise-grade features at Datical.
-The last question of the Liquibase Community Survey is a question on whether I can follow up to learn more from you.
-As a part of this follow-on, the team at Datical would love to connect with those of you willing to spare a half hour so they can better understand how to provide continued corporate support for this open source project while continuing to build out a commercial roadmap.
-So, as you are taking the community survey, I encourage you to be open to the follow-up as it only helps me and the team at Datical figure out how to best balance the needs of the open source community and the commercial market.
-
-Thanks for your input! I’m looking forward to hearing what each of you has to say.
-
-### -----> [Liquibase Survey 2018 Form](https://goo.gl/forms/Atzmtw7XZatOehuP2) <----- ###
diff --git a/_posts/2018-04-11-liquibase-3-6-0-released.md b/_posts/2018-04-11-liquibase-3-6-0-released.md
deleted file mode 100644
index b981c2b02..000000000
--- a/_posts/2018-04-11-liquibase-3-6-0-released.md
+++ /dev/null
@@ -1,133 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.6.0 Released
----
-# Liquibase 3.6.0 Released
-
-Liquibase 3.6.0 (actually 3.6.1 as well) is now available from [liquibase.org/download](http://liquibase.org/download) and through the Maven repositories. Question or comments can be directed [to liquibase.org/community](http://liquibase.org/community)
-
-Version 3.6.0 is primarily a bugfix release, but there have been over new 1000 commits since the 3.5.x series, so TONS of good new things.
-
-### Highlights include
-
-- Improved database support for MS SqlServer, Oracle, Sybase, DB2 on Z/OS and others
-- Improvements to spring and includeAll handling
-- UTF-8/Non-ASCII fixes
-- And much more
-
-### Checksum logic change
-
-The 3.6.0 release should be a drop-in replacement for anyone using Liquibase, but some of the bugfixes required an update to the checksum logic.
-
-This means that when you first run an update command, Liquibase will transparently replace the old version with the new version BUT it will not be able to detect whether they actually changed or not, so any "runOnChange" triggers will NOT execute on the first run of the upgrade.
-
-### Looking Forward: API Changes
-
-The main goal of 3.6.0 was to collect all the outstanding bugfixes and minor features into a base release to build on for future changes.
-
-Part of the reason for the gap between 3.5 and 3.6 is that I have been busily working on an extensive code cleanup/re-organization task in Liquibase concurrently and it has proved too difficult to keep the two branches in sync.
-I had been making the changes in a separate branch because I've always tried to keep API-compatibility between releases to avoid breaking extensions, and the clean-up work is the point where I'm needing to break some of those APIs in order to support future functionality.
-
-Unfortunately, it has gotten too difficult to manage both branches in parallel and the progress in both has suffered, so I am going to take a new approach: starting with the 3.7.0 release, I am going to be making API-breaking changes from release to release until they finished, at which point we will release 4.0.0 and resume the normal no-API-breaking-changes rule.
-This change only affects users of Liquibase extensions--*changelogs will ALWAYS backwards compatible.*
-
-With each 3.x release, I will document any code migration changes needed as part of the release notes, but for those who prefer to wait for the final 4.0 stable release to update your extensions I will continue to provide bugfixes for 3.6.x even as newer versions come out.
-
-As an example of changes I'm planning on making, I have already started pulling out the custom ServiceLocator logic that causes so much pain with the standard java.util.ServiceLoader classes.
-
-### Looking Forward: Project Infrastructure Changes
-
-To simplify issue management, I'm going to migrate our issue tracking from Jira to Github. I'll post an announcement as that is finished.
-
-I am finishing up re-introduction of a public build server and snapshot builds. I'll post an announcement as that is finished.
-
-### REMINDER: Community Survey Ends Saturday April 14th.
-
-It should only take a few minutes to fill out and is a huge help in understanding how Liquibase is used and how we can improve.
-
-[Liquibase Survey 2018 Form](https://goo.gl/forms/Atzmtw7XZatOehuP2)
-
-
-### Full Release Notes
-
-Thanks to everyone who helped with [all these issues](https://liquibase.jira.com/secure/ReleaseNote.jspa?projectId=10020&version=13060)
-
-- [CORE-1609] - Command Prompt: Can't connect to database with a special character in pwd
-- [CORE-1852] - checksums depend on environment
-- [CORE-1888] - Sybase error for TINYINT, INT, BIGINT: Can’t specify a length, scale or storage property on type ‘int/tinyint/bigint’.
-- [CORE-2008] - H2 Supports minValue and maxValue in Sequences since Version 1.3.175, but Liquibase does not
-- [CORE-2033] - NPE during Diff when case sensitive table missing
-- [CORE-2135] - liquibase corrupting UTF-8 changesets
-- [CORE-2162] - MSSQL: Multiple inserts in sqlFile do not fail as expected
-- [CORE-2191] - Update on SQL Azure database fails due to unavailable sys.extended_properties
-- [CORE-2527] - Sybase create table fails because column name is too long
-- [CORE-2631] - dbdoc does not specify content type
-- [CORE-2739] - --delimiter parameter in liquibase --help
-- [CORE-2747] - CreateView / Oracle: Keyword REPLACE in view definition prohibits "or replace" in DDL statement
-- [CORE-2772] - primaryKeyExists check fails on Turkish locale for some chars
-- [CORE-2773] - DB2 AS/400 - generateChangeLog throwing Exception
-- [CORE-2796] - Handle TimeStamps with nano second precision correctly
-- [CORE-2797] - Determine the DB2 data server type correctly
-- [CORE-2820] - Unsupported ReorganizeTable for DB2 z/OS causes changelog validation to fail
-- [CORE-2821] - AddForeignKey statement generates incorrect SQL for DB2 z/OS
-- [CORE-2826] - indexExists precondition fails on AS400 + JDBCDatabaseSnapshot/Snapshot generator code is not coded generically?
-- [CORE-2843] - Sql wrong lexical analysis for string literals - escaped single quotes are misparsed
-- [CORE-2875] - UTF-8 character not understood
-- [CORE-2894] - Oracle snapshot not detecting custom datatypes in different schemas
-- [CORE-2909] - column remarks for mysql should be escaped
-- [CORE-2911] - Oracle: generateChangeLog on RAW types not including the size param
-- [CORE-2928] - Invalid snapshot of "duplicate" foreign keys
-- [CORE-2929] - Views with definitions that start with a comment are not captured correctly in generateChangeLog
-- [CORE-2940] - Do not print warning when DBA_RECYCLEBIN is not available
-- [CORE-2944] - outputDefaultSchema and outputDefaultCatalog command line parameters not respected
-- [CORE-2953] - update with valueSequenceNext and schema produces wrong SQL on oracle
-- [CORE-2965] - Custom Properties XML Changelog
-- [CORE-2992] - liquibase.util.grammar.TokenMgrError: Lexical error at line 1, column 71. Encountered: "\u00b4" (180), after : ""
-- [CORE-2993] - createSequence with order denied on DB2
-- [CORE-3002] - SQLAnywhere: Revert Unique Index failed
-- [CORE-3006] - Oracle CSV-Import: "String index out of range: -1"
-- [CORE-3009] - SQLAnywhere: Drop Default Value failed
-- [CORE-3020] - No warning when included file doesn't exist (missing extension)
-- [CORE-3033] - typo in postgresql reserverd word
-- [CORE-3040] - onlyUpdate="true" flag generates empty statements for MySQL DB
-- [CORE-3046] - Fix faulty snakeyaml class-path entry after upgrade to 1.17
-- [CORE-3051] - SQLAnywhere: Drop Table does not support CASCADE
-- [CORE-3054] - SQLAnywhere: java-coredump on changeSet-SQL
-- [CORE-3055] - SQLAnywhere: supports Sequences
-- [CORE-3063] - Integration tests failing on master
-- [CORE-3069] - Checksum: line endings not standardized on windows if multiple lines
-- [CORE-3072] - Add usePreparedStatements="true|false" flag to loadData
-- [CORE-3076] - SUM is not reserved word for HsqlDB
-- [CORE-3099] - Non English environment; invalid tablename and column name can be generated because of toUpperCase toLowerCase method which is dependent to locale in java
-- [CORE-3101] - dropPrimaryKey TABLE_SCHEMA = 'null'
-- [CORE-3106] - SQLAnywhere: DROP INDEX should use tablename
-- [CORE-3115] - Prefix space in column type causing the Unknown LiquibaseDataType with the latest release
-- [CORE-3117] - TIMESTAMP WITH TIME ZONE datatype is changed to TIMESTAMP in H2
-- [CORE-3119] - Maven failing to use driverPropertiesFile from Liquibase Properties File
-- [CORE-3135] - Column t1.tgconstrname does not exist
-- [CORE-3138] - SQLAnywhere: AddAutoIncrement-Statement is wrong
-- [CORE-3140] - MSSQL2005 doesn't support built-in function original_db_name()
-- [CORE-3155] - CSV line content behind inline comment character doesn't contribute to checksum
-- [CORE-3162] - Diff problem with MSSQL case sensitive database
-- [CORE-3171] - LoadUpdateData doesn't work on SAP SQLAnywhere
-- [CORE-3180] - A DBMS-specific change set referencing a DBMS-specific rollback can't be parsed on a different DBMS
-- [CORE-2735] - Add possibility to test rollback with SpringLiquibase
-- [CORE-1225] - Add support for tablespace assigned to liquibase metadata tables
-- [CORE-2628] - defaultSchema parameter doesn't do Connection.setCatalog() for SpringLiquibase
-- [CORE-2842] - MSSQL: Support creating clustered unique constraints
-- [CORE-2891] - Liquibase "Command" objects can be extended and overridden
-- [CORE-2919] - Make all variants of Liquibase.listUnrunChangeSets public
-- [CORE-2952] - Use the clustered index if duplicate indexes are defined
-- [CORE-2955] - MSSQL: Capture explicit null default values on snapshot and generate/diffChangeLog
-- [CORE-2970] - MSSQL: Support default value constraint names
-- [CORE-2977] - Generated primary key constraint name doesn't match Postgres default
-- [CORE-2985] - MSSQL Snapshot performance improvements
-- [CORE-3000] - Oracle JDBC batch for load_data
-- [CORE-3005] - Consideration of DB2/400 system views
-- [CORE-3017] - Add path attribute to createView
-- [CORE-3018] - Oracle: support remarks on createView
-- [CORE-3045] - Support indexes on views
-- [CORE-3079] - Make includeObjects and excludeObjects affect which objects are snapshotted
-- [CORE-3094] - HSQLDB UUID support
-- [CORE-2920] - Using "//" as an endDelimiter stopped working 3.5.0
\ No newline at end of file
diff --git a/_posts/2018-06-30-liquibase-3-6-2-released.md b/_posts/2018-06-30-liquibase-3-6-2-released.md
deleted file mode 100644
index b86177b49..000000000
--- a/_posts/2018-06-30-liquibase-3-6-2-released.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.6.2 Released
----
-# Liquibase 3.6.2 Released
-
-Liquibase 3.6.2 is now available from [liquibase.org/download](http://liquibase.org/download) and through the Maven repositories. Question or comments can be directed [to liquibase.org/community](http://liquibase.org/community)
-
-Version 3.6.2 is a bugfix release while we work on a 3.7.0 release.
-
-### Fixes include
-
-- Fixed breaking API change
-- Improvements to spring boot includeAll
-- Oracle 11g doesn't support TIMESTAMP WITHOUT TIME ZONE data type
-- Fix in PostgreSQL dropPrimaryKey with objectQuotingStrategy="QUOTE_ALL_OBJECTS"
-
diff --git a/_posts/2018-07-23-austin-liquibase-meetup.md b/_posts/2018-07-23-austin-liquibase-meetup.md
deleted file mode 100644
index c0918399d..000000000
--- a/_posts/2018-07-23-austin-liquibase-meetup.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Austin Liquibase Meetup
----
-# Austin Liquibase Meetup
-
-Austin Liquibase Meetup, Wed Sept 12, 2018
-
-Mark your calendars!
-
-More Info
\ No newline at end of file
diff --git a/_posts/2018-11-27-next-level-changelog.md b/_posts/2018-11-27-next-level-changelog.md
deleted file mode 100644
index fc8124f77..000000000
--- a/_posts/2018-11-27-next-level-changelog.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Taking the XML changeset and changelog workflows to the next level
----
-# Taking the XML Changeset and Changelog Workflows to the Next Level
-
-As many of you know, a few years after starting the Liquibase open-source project, I joined the team at Datical.
-For those who are unaware, Datical is a commercial solution built on top of Liquibase.
-
-Datical is also the primary maintainer of the Liquibase open source project - though we are always looking for more engaged community members who might be interested in being stewards to the project along with me.
-
-While I’ve enjoyed the years of growth - both Liquibase and Datical have seen, I had always hoped for a better transition from the open-source project I founded to the commercial software that I now help architect.
-
-Finally, the wait is over – and I’m tremendously excited to announce that Datical’s latest release supports users bringing in their own XML changesets and changelogs from Liquibase.
-
-*This new capability is a major milestone.*
-I’ve heard from your, the open-source community time and again that being able to describe database changes in an object model is much more approachable than having to writing everything in SQL – especially when delivering software runs against a number of different backend database platforms.
-
-Now, you can continue working with the Liquibase XML model, using the same workflow and practices that you have established across your team while upgrading to Datical when the time is right.
-
-While Liquibase is a great solution for smaller teams, projects, and organizations, it has a number of limitations at enterprise scale.
-With this new capability, it becomes possible for teams to continue using Liquibase at enterprise scale, while seamlessly integrating and leveraging Datical behind the scenes to meet enterprise needs.
-I’ve heard of many cases where large organizations have put enormous effort into customizing and updating Liquibase with an internally forked version to meet their needs.
-While some of these projects have been rather successful, many eventually suffer from neglect as it becomes more difficult to maintain, scale, adapt the solution as time passes and as more teams want access.
-
-There is now a new way forward. Already there has been many notable organizations, including Athene, MedImpact, and Zions Bancorporation, that started with Liquibase and moved to Datical.
-But now, instead of making a transition to Datical and requiring developers to write SQL, organizations can move to Datical while empowering their development teams to have a choice between writing XML changesets and SQL.
-
-I’m excited about this news. If you are curious about how this works the team at Datical has pulled together a demo video that illustrates how the Liquibase workflow can seamlessly benefit from Datical’s advanced enterprise capabilities.
-You can also learn more here.
diff --git a/_posts/2019-01-29-liquibase-3-6-3-released.md b/_posts/2019-01-29-liquibase-3-6-3-released.md
deleted file mode 100644
index 24feea70a..000000000
--- a/_posts/2019-01-29-liquibase-3-6-3-released.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.6.3 Released
----
-# Liquibase 3.6.3 Released
-
-Liquibase 3.6.3 is now available from [liquibase.org/download](http://liquibase.org/download) and through the Maven repositories. Question or comments can be directed [to liquibase.org/community](http://liquibase.org/community)
-
-Version 3.6.3 is a bugfix release while we work on a 3.7.0 release.
-
-### Fixes include
-
-- Better including SLF4 libraries
-- Fixes to includeAll and other file loading/finding logic
-- Many other misc fixes
-
-Full release notes are available from [https://liquibase.jira.com](https://liquibase.jira.com/secure/ReleaseNote.jspa?projectId=10020&version=13504)
diff --git a/_posts/2019-05-09-updates-to-hibernate-hana-extensions.md b/_posts/2019-05-09-updates-to-hibernate-hana-extensions.md
deleted file mode 100644
index 0c2f8b2e5..000000000
--- a/_posts/2019-05-09-updates-to-hibernate-hana-extensions.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Updates to Liquibase Hibernate and HANA extensions
----
-# Updates to Liquibase Hibernate and HANA Extensions
-
-We have reviewed and accepted pull requests for extensions that add and enhance support for Hibernate and HANA. Hibernate is one of the most popular Java ORMs and SAP HANA powers critical ERP, CRM, and SRM systems.
-
-### Check out what's new with the Hibernate extension
-The updated Liquibase Hibernate extension improves:
-
-- Support for latest Liquibase core releases (3.6)
-- Support for Bean validation annotation
-- Better handling of indexes and constraints
-- Better handling of physicalNamingStrategy
-- Support for using sequence start values
-
-[Download the Hibernate extension] (https://github.com/liquibase/liquibase-hibernate/releases/tag/liquibase-hibernate5-3.7)
-
-### Check out what’s new with the HANA extension
-The updated Liquibase HANA extension supports the latest Liquibase 3.6.3 release and adds a ton of functional improvements to HANA support. A huge thanks to [Jonathan Bregler](https://github.com/breglerj) Software Engineer at SAP, for all of the work he contributed to Liquibase HANA support.
-
-[Download the HANA extension](https://github.com/liquibase/liquibase-hanadb/releases/tag/liquibase-hanadb-2.0)
-
-### Download the extension updates
-- [Download the Hibernate extension](https://github.com/liquibase/liquibase-hibernate/releases/tag/liquibase-hibernate5-3.7)
-- [Download the HANA extension](https://github.com/liquibase/liquibase-hanadb/releases/tag/liquibase-hanadb-2.0)
-
-Or, you can download both extensions from the [central Maven repository](https://mvnrepository.com/repos/central).
-
-Want to learn more about Liquibase extensions? [View the Liquibase Extensions Portal](https://liquibase.jira.com/wiki/spaces/CONTRIB/overview).
-
-### Download Liquibase
-[Download the current version of Liquibase 3.6.3](https://download.liquibase.org/), source control for your database.
-
-Thanks for your continued support. Enjoy the updated extensions.
diff --git a/_posts/2019-07-19-liquibase-3-7-0-released.md b/_posts/2019-07-19-liquibase-3-7-0-released.md
deleted file mode 100644
index 458b654e2..000000000
--- a/_posts/2019-07-19-liquibase-3-7-0-released.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.7.0 Released
----
-# Liquibase 3.7.0 Released
-
-Liquibase 3.7.0 is now available from [liquibase.org/download](http://liquibase.org/download) and through the Maven repositories. Questions or comments should be directed [to liquibase.org/community](http://liquibase.org/community).
-
-Version 3.7.0 is primarily a bugfix release, but there have been over 350 commits since 3.6.3, so TONS of good new things from both the community and Datical.
-
-### Highlights Include
-- Improved support for PostgreSQL, DB2, MariaDB, MS SqlServer, Ingres, and Firebase
-- Support for not validated not-null constraints
-- Performance improvements
-- Changelog parameters can be set via environment variables
-- includeAll bugfixes
-- can filter by id, author, or labels
-- Allow disabling shouldRun in CDI
-- And much more
-
-Thanks to everyone who helped with [all these issues](https://liquibase.jira.com/secure/ReleaseNote.jspa?projectId=10020&version=13501)
diff --git a/_posts/2019-07-23-survey-2018-results.md b/_posts/2019-07-23-survey-2018-results.md
deleted file mode 100644
index f0fb06066..000000000
--- a/_posts/2019-07-23-survey-2018-results.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: What We Learned from the 2018 Liquibase Community Survey
----
-# What We Learned from the 2018 Liquibase Community Survey
-
-Last year, we invited the Liquibase community to take a survey to help us understand how Liquibase is used and how we can improve.
-A small sample size from our community (a little over 200 people out of 4M+ downloads in the past 12 months) participated via the Liquibase.org website. Here’s what we learned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-### Summing it up
-
-* Liquibase is used by companies of all sizes.
-* Most Liquibase users find the tool useful and use extensions to meet their needs.
-* Although most users find the documentation helpful, we’d love to see that number higher than 68%. We’ll look at improving the documentation and providing links in more helpful places in the near future.
-
-We also took the time to interview a handful of users to ask more in-depth questions to see what features they’re looking for. More on that soon.
-
-Thanks to all that participated in the survey and interviews! We look forward to making improvements and getting more feedback from the community.
diff --git a/_posts/2019-08-07-improving-community-support.md b/_posts/2019-08-07-improving-community-support.md
deleted file mode 100644
index c4f8ce1e2..000000000
--- a/_posts/2019-08-07-improving-community-support.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Improving Community Support
----
-# Improving Community Support
-
-It’s an exciting time for the Liquibase community. The latest release, 3.7, has over 350 commits from the community and from Datical.
-Datical has dedicated several engineers to the Liquibase open source project.
-Most recently, these efforts helped push the [Liquibase 3.7 release](/2019/07/liquibase-3-7-0-released.html) with several important new features including improved support for PostgreSQL, DB2, MariaDB, MS SqlServer, Ingres, and Firebase, and much more.
-
-### Liquibase Community Manager
-
-I’m very excited to share that we are looking to hire an [open source community manager](https://www.datical.com/company/careers/?gh_jid=1803669).
-This position will be vital to the community, helping to manage and improve the website and forum.
-They’ll also be responsible for responding to questions and comments as well as connecting with users to help improve everyone’s experience with Liquibase.
-If you’re passionate about building open source communities, [I encourage you to apply!](https://www.datical.com/company/careers/?gh_jid=1803669)
-
-> *NOTE* As of December 2019, this position has been filled. Contact the community manager with your questions and suggestions!
-
-### Strategic Partnerships
-
-In addition to dedicating developers to the project, the Datical team has been investing in strategic partnerships with Cassandra, CockroachDB, Couchbase, and SAP HANA, among others, to increase community contribution.
-Look for more updates in the near future from these partnerships.
-
-We’re committed to increasing our investment in Liquibase by adding to the capabilities, news, documentation and community contribution.
-Look for more news and announcements by following [@Liquibase](https://twitter.com/Liquibase) and [@Datical](https://twitter.com/Datical) on Twitter.
diff --git a/_posts/2019-08-28-liquibase-3-8-0-released.md b/_posts/2019-08-28-liquibase-3-8-0-released.md
deleted file mode 100644
index ecde8869e..000000000
--- a/_posts/2019-08-28-liquibase-3-8-0-released.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.8.0 Released, adds new Pro features
----
-# Liquibase 3.8.0 Released, Adds New Pro Features
-
-Liquibase 3.8.0 is now available from [liquibase.org/download](http://liquibase.org/download) and through the Maven repositories. Release notes are available at [https://liquibase.jira.com](https://liquibase.jira.com).
-
-Liquibase now comes in two modes:
-
-* Liquibase Community
-* Liquibase Pro
-
-The 3.8.0 release adds the ability to enter a license key for a Liquibase Pro trial or full Liquibase Pro license.
-
-### Liquibase Community
-
-Liquibase is open source now and always. We’ll continue to provide the great Apache v2-licensed database change and version control tool you know and love. We’re excited to provide better documentation, better community support and more functionality for many future releases.
-
-### Liquibase Pro
-
-Liquibase Pro gives teams an option to get support and expert answers for their use case so they don’t have to go it alone. Liquibase Pro also adds functions to change sets for updating procedural database code. Liquibase Pro is available under a commercial license as a yearly subscription. A free 14-day trial is available. No credit card is required. [Learn more about Liquibase Pro](https://download.liquibase.org/)
-
-## We’re hiring!
-
-### Liquibase Support Engineer
-
-We are looking for a Liquibase expert to elevate the Liquibase support experience. This position can be remote, part-time or full-time. Check out the details here: [https://www.datical.com/company/careers](https://www.datical.com/company/careers/?gh_jid=1827858)
-
-### Liquibase Developer Advocate
-
-We’re continuing our search for a Developer Advocate/Community Manager. Check out the details here: [https://www.datical.com/company/careers](https://www.datical.com/company/careers/?gh_jid=1803669)
diff --git a/_posts/2019-11-06-liquibase-3-8-1-released.md b/_posts/2019-11-06-liquibase-3-8-1-released.md
deleted file mode 100644
index ae6d9aa12..000000000
--- a/_posts/2019-11-06-liquibase-3-8-1-released.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.8.1 Released
----
-# Liquibase 3.8.1 Released
-
-Liquibase 3.8.1 is now available here through [Liquibase.org](https://download.liquibase.org/download-community/) and through
-the [Maven repositories](https://mvnrepository.com/artifact/org.liquibase/liquibase-core). The [3.8.1 release is also available on GitHub](https://github.com/liquibase/liquibase/releases/tag/v3.8.1).
-
-Here’s a closer look at what’s included in the latest release.
-
-## Liquibase Bug Fixes & Doc Updates
-
-Both Liquibase Community and Liquibase Pro users will enjoy several bug fixes and updates to documentation.
-[View 3.8.1 release notes](https://download.liquibase.org/release-notes/liquibase-3-8-1/) for details on these updates.
-
-## New Liquibase Pro Features
-
-### Snapshots and Reverse Engineering for Stored Logic
-In this 3.8.1 release, Liquibase Pro users with workloads on Oracle and SQL Server are able to capture information on their **Stored Logic**.
-
-The ability to snapshot Stored Logic allows you to get a static view of your database at a particular point in time and is useful for reporting and
-safeguarding your data by comparing databases (performing diffs) to find differences.
-
-Liquibase Pro users will also now include Stored Logic changeSets in changelogs generated through the **diffChangeLog** and **generateChangeLog** command.
-
-**Stored Logic** objects include:
-
- - Check Constraint
- - Procedures
- - Package
- - Package Body
- - Function
- - Trigger
- - Synonyms
-
-### A Much More User-Friendly Changelog
-If stored logic code gets written directly into the Liquibase **changelog**, the file can get very cluttered. Additionally, **Stored Logic** code is often formatted and that
-formatting can be lost when it’s written to the **changelog**.
-
-With the 3.8.1 release, Liquibase Pro now eliminates the clutter by making the **changelog** more concise and readable, allowing users to maintain formatting by outputting
-the Stored Logic code via external files that can be referenced by the changelog. SQL files are organized in directories by object type, making them easy to find.
-
-### Avoid Oracle Slowdowns
-Liquibase Pro users have access to a new, Oracle-specific change type, `markUnused`, that helps users avoid database slowdowns caused by dropping a populated column.
-`markUnused` tells Oracle to mark columns as 'unused' rather than dropping them immediately, which allows DBAs to decide the best time to drop these columns for
-their particular application. This feature was first added in 3.8.0, and now with 3.8.1 it is possible to use the **diffChangeLog** and **generateChangeLog** commands and
-have the generated changesets mark dropped columns as unused. The default is `markUnusedNotDrop=false` which will continue to drop columns rather than mark them unused. To
-override this, you will need to set the system property `liquibase.pro.markUnusedNotDrop` to `true`.
-
-## Summing it up
-Take advantage of all of these new features with a [free 14-day trial of Liquibase Pro](https://download.liquibase.org/liquibase-pro-trial-request-form/). In addition to
-enhanced features, Liquibase Pro users also receive experienced guidance and fast troubleshooting from our excellent Liquibase support team. With their help, you’ll save
-countless hours of scouring Stack Overflow forums if you get stuck. They’re also great at getting your team up and running with Liquibase in a way that works best for your
-use case. [Give it a try](https://download.liquibase.org/liquibase-pro-trial-request-form/). No credit card is required so you don’t have to worry about forgetting to cancel.
-
-### Giving Back to the Community
-We’ve added some Liquibase Pro features in this latest release, but we’re also continuing to fix bugs and improve documentation for everyone in the Liquibase community.
-Our community has built a lot. From extensions to integrations, you’ve helped make Liquibase the amazing open source project that it is today. We want to help make it
-stronger. Here are some ways to contribute:
-- [Contribute code](https://www.liquibase.org/development/contribute.html)
-- [Make doc updates](https://github.com/liquibase/liquibase.github.com/tree/master/documentation)
-- Participate in our upcoming community survey (look for an update on this soon)
-
-Stay tuned for more website improvements, tutorials, videos, and demos. Check out the latest on our [Liquibase Expert Exchange](https://download.liquibase.org/expert-exchange/).
diff --git a/_posts/2019-11-26-liquibase-3-8-2-released.md b/_posts/2019-11-26-liquibase-3-8-2-released.md
deleted file mode 100644
index 8568f0320..000000000
--- a/_posts/2019-11-26-liquibase-3-8-2-released.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.8.2 Released
----
-# Liquibase 3.8.2 Released
-
-Liquibase 3.8.2 is now available here through [Liquibase.org](https://download.liquibase.org/download-community/).
-The [3.8.2 release is also available on GitHub](https://github.com/liquibase/liquibase/releases/). Here’s a closer look at what's included in the latest release.
-
-## Liquibase 3.8.2 Overview
-
-### Snapshots and Reverse Engineering Expands to Postgres and DB2
-TL;DR: With the release of Liquibase 3.8.2, Liquibase Pro users with workloads on PostgreSQL and DB2 are now able to capture and export Stored Logic objects. These Stored Logic objects will now export into local directories and files, making them easier to organize and manage.
-This release also includes several bug fixes for Liquibase Community and Pro.
-
-## What's New in Version 3.8.2
-### Snapshots and Reverse Engineering for PostgreSQL and DB2
-The ability to snapshot Stored Logic for Postgres and DB2 allows users to get a static view of the database at a particular point in time and is useful for reporting and safeguarding data by comparing databases (performing diffs) to find differences.
-Liquibase Pro users will also now be able to include Stored Logic changeSets in changelogs generated through the **diffChangeLog** and **generateChangeLog** command. Users can reverse engineer Stored Logic changes using generateChangeLog, snapshot, diff, and diffChangeLog commands.
-
-**Stored Logic** objects include:
-
- - Check Constraint
- - Procedures
- - Package
- - Package Body
- - Function
- - Trigger
- - Synonyms
-
-### A Much More User-Friendly Changelog for PostgreSQL and DB2 Stored Logic Users
-If Stored Logic code gets written directly into the Liquibase changelog, the file can get very cluttered. Additionally, Stored Logic code is often formatted and this formatting can be lost when it’s written to the changelog.
-Liquibase Pro eliminates the clutter by making the changelog more concise and readable, allowing users to maintain formatting by outputting the Stored Logic code via external files that can be referenced by the changelog. SQL files are organized in directories by object type, making them easy to find.
-
-**Try Liquibase Pro**
-
-Take advantage of all of these new Liquibase Pro features with a [free 14-day trial](https://download.liquibase.org/liquibase-pro-trial-request-form/). In addition to enhanced features, Liquibase Pro users also receive experienced guidance and fast troubleshooting from our excellent Liquibase support team.
-
-### Bug Fixes
-For both Liquibase Community and Liquibase Pro users, the following bugs were fixed in version 3.8.2:
- - Using generateChangeLog/diffChangeLog to generate formatted SQL changelogs now works with Liquibase Pro's stored logic support
- - CDI-related classes moved back out of the main Liquibase jar into an optional jar
- - Fixed issue with indexes backing foreign keys not always being captured in diffChangeLog/generateChangeLog
- - Fixed issue with diffChangeLog/generateChangeLog generating primary keys when column order doesn't match the table's column order
-
-## Take the Liquibase Community Survey
-We have opened our Liquibase Community Survey! This is your opportunity to help us concentrate on the features and functionality that you want to see added to Liquibase.
-
-It only takes about 5 minutes and the first 1000 responses receive a gift card. Handy for the holidays!
-
-[Take the Liquibase Survey](https://www.surveymonkey.com/r/Liquibase-Survey-B)
diff --git a/_posts/2019-12-04-5-ways-fix-bad-database-change.md b/_posts/2019-12-04-5-ways-fix-bad-database-change.md
deleted file mode 100644
index 60e5da237..000000000
--- a/_posts/2019-12-04-5-ways-fix-bad-database-change.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: 5 Ways to Fix a Bad Database Change in Liquibase
-author: Steve Donie
----
-# 5 Ways to Fix a Bad Database Change in Liquibase
-
-You’ve just run a `liquibase update`. Moments later, your stomach churns as you realize that there were some big mistakes in the changes you just deployed and your database is definitely not in the state you intended. What do you do now?
-**Don’t panic. You’ve got options.**
-
-When you’ve made a bad database change, you have a number of options for dealing with changes you have already deployed using Liquibase. How best to proceed depends on your specific scenario.
-
-First, let’s focus on fixing up the environment where the bad database change was made. We won’t worry about upstream or downstream environments just yet as they may or may not have the same changes already deployed to them.
-
-## Roll changes forward
-This is the beauty of database migrations and making small changes incrementally. By rolling the changes forward (some call this fixing forward), you simply add a new changeset to address the issue(s) caused by the deployment of previous change(s). Running a `liquibase update` is the best way to get rid of bad database changes that you’ve made. We strongly encourage using this option whenever possible.
-
-For example, let's say that you just added a new column to a database. Your changeset looks like this:
-
-{% highlight xml %}
-
-
-
-
-
-
-{% endhighlight %}
-
-You start doing your testing and you realize that ten characters is definitely not wide enough. To fix forward, add another changeSet that widens that column to the desired size:
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-And off you go on your merry way!
-
-## Include a rollback script with every changeset
-This option requires a lot of discipline as it involves creating a valid rollback for every. single. change. [Documentation on Liquibase rollbacks](/documentation/rollback.html).
-
-By choosing the rollback script option, you will need to manually validate that the rollback for each changeset properly rolls back the change made by the changeset. Liquibase can/will auto-generate rollbacks for purely additive changes. For example, if you use the ‘create table’ command, Liquibase can generate a ‘drop table’ – but this is ONLY if you are using a Liquibase function and will not work if you’re pointing to a SQL file, using the SQL tag, or using a formatted SQL changelog. The best practice is to author rollbacks for every change (which you can do in any/all changelog formats) if you foresee the need to roll back.
-
-Additionally, note that Liquibase will serially roll back changes to whatever point you want. There is no means to roll back a specific change that has previously been deployed. You have to roll back the changes in the reverse order that they were deployed.
-
-For example, you have the following changes deployed to a database and they all have a corresponding rollback script (A’, B’, C’, D’).
-
-
-
-Let’s say you want to roll back change ‘B’. Liquibase will only allow you to roll back change B by applying D’, C’ and B’ (basically rolling back D, C, and B) in order to “rollback change B”.
-
-
-
-If you attempt a rollback to a change and Liquibase does NOT have a valid rollback script for one of the changes in the sequence, the rollback operation will fail and nothing will be rolled back. Liquibase performs this check before it starts applying any rollbacks, so no harm is done, but nothing will happen. The state of your database will remain exactly the way it is.
-
-## Drop, rework, and deploy
-If you are working in a sandbox/developer environment, this option is for you. You can run a `liquibase dropAll` to drop everything from the database. (Do NOT use this in production!) Once you have a clean sandbox, you can edit any changesets you want to, and then run a `liquibase update` to deploy the changes you want. This is a great option for iterative development if (and only if) you have a sandbox environment where you have the luxury of dropping all objects.
-
-## Restore from backup
-This option only works if you have a backup and the ability to take the downtime to restore from a backup. It’s operating outside of Liquibase but is a path to resolution.
-
-## Do it live
-This option is also operating outside of Liquibase and when you do not have a backup or ability to restore from a backup.
-With this option, you connect to the database and beat it into the state you desire. It’s unequivocally the worst of all options. If you ever want these fixes to apply to other environments, it will definitely require some combination of using `validCheckSum`, `diffChangelog`, `changelogSync`, etc. depending on the specifics of what you actually do by hand. Undoubtedly, it is STRONGLY recommended you do NOT use this option, and that you talk your DBAs out of resorting to this option; bribe them if you must!
-
-## Summing it up
-Bad database changes happen. Depending on your situation and needs, there are several ways to handle a bad database change when you’re using Liquibase. We always recommend rolling forward whenever possible, but it’s good to know all of your options.
diff --git a/_posts/2019-12-16-Recent-Liquibase-Articles.md b/_posts/2019-12-16-Recent-Liquibase-Articles.md
deleted file mode 100644
index 9028e85e3..000000000
--- a/_posts/2019-12-16-Recent-Liquibase-Articles.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Recent Liquibase Articles, December 2019
-author: Steve Donie
----
-# Recent Liquibase Articles, December 2019
-
-Here are some recent mentions of Liquibase on other sites.
-
-* [Fear database changes? Get them under control with CI/CD](https://dev.to/heroku/fear-database-changes-get-them-under-control-with-ci-cd-44n1)
- 17 December 2019
-
- Why you should be including database concerns in your CI/CD process.
-
-* [Evolving Database using Spring Boot and Liquibase](https://www.roytuts.com/evolving-database-using-spring-boot-liquibase/)
- 16 Dec 2019
-
- Nice tutorial showing how to evolve your database over time, using YAML and SQL Configuration rather than XML. The author also has
- several other Liquibase related articles.
-
-* [Six Reasons You Should Try Liquibase for Your Next Project](https://medium.com/@texorcist/6-reasons-you-should-try-liquibase-for-your-next-project-47c5bf86ca9)
- 3 Dec 2019
-
- Datical's CTO Robert Reeves talks about why Liquibase is awesome.
-
-* [Liquibase and Titan: Open Source Database DevOps](https://medium.com/@texorcist/liquibase-and-titan-open-source-database-devops-bdeb19be4181)
- 27 September 2019
-
- Robert Reeves shows how Titan + Liquibase is a great model for working with databases in the development workflow. Titan is "docker for databases" and
- provides a great system for getting data into the hands of software developers.
-
-* [SpringBoot, Liquibase, and MariaDB](https://medium.com/@texorcist/6-reasons-you-should-try-liquibase-for-your-next-project-47c5bf86ca9)
- 24 September 2019
-
- Tutorial and Quick Start on using Liquibase with SpringBoot.
-
-
-* [Software Development Tools I Won't Do Without](https://medium.com/@stevedonie/software-development-tools-i-wont-do-without-58478d204d94)
- 9 November 2016
-
- An older article I wrote that describes why tools like Liquibase are as essential to the software development process as source control, testing,
- and continuous integration.
-
diff --git a/_posts/2019-12-17-liquibase-3-8-3-released.md b/_posts/2019-12-17-liquibase-3-8-3-released.md
deleted file mode 100644
index b4ae349e4..000000000
--- a/_posts/2019-12-17-liquibase-3-8-3-released.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.8.3 Released, Improves Maven Plugin Support
----
-# Liquibase 3.8.3 Release, Improves Maven Plugin Support
-
-Liquibase 3.8.3 is now available here through [Liquibase.org](https://download.liquibase.org/download-community/).
-The [3.8.3 release is also available on GitHub](https://github.com/liquibase/liquibase/releases/). Here's a closer look at what's included in the latest release.
-
-## Liquibase 3.8.3 Overview
-
-### Improved Support for Liquibase-Maven Plugin and Java 9+
-When you try to make a lot of improvements really fast, sometimes things can break. Thanks for letting us know that there was an issue with our last point release with Maven. We wanted to remedy this as quickly as possible. We're very happy to report with the release of Liquibase 3.8.3, users of both Liquibase Community and Liquibase Pro can enjoy improved Liquibase-Maven plugin experiences, especially when using Java 9+.
-
-### Bug Fixes
-The following bugs were fixed in version 3.8.3:
-- Liquibase-Maven plugin now works with Java 9+.
-- Expired license messages are now less annoying. (We made them less verbose and less excitable.)
-
-### Documentation
-All Liquibase users should also check out our continually improving documentation. For this release, there are two pages of special interest:
-- [Maven Liquibase Plugin](/documentation/maven/index.html)
-- [How to Get Oracle Drivers using Maven](/documentation/maven/maven-get-oracle-drivers.html)
-
-Full Liquibase documentation is available at [https://www.liquibase.org/documentation/index.html](/documentation/index.html).
-
-### Get Involved
-You can help make the Liquibase community better by contributing in the following ways:
-- Contribute code - [https://www.liquibase.org/development/contribute.html](https://www.liquibase.org/development/contribute.html)
-- Make documentation updates - [https://github.com/liquibase/liquibase.github.com/tree/master/documentation](https://github.com/liquibase/liquibase.github.com/tree/master/documentation)
-- Participate in our community survey and earn $10 for 10 minutes of your time - [https://www.surveymonkey.com/r/Liquibase-Survey-B](https://www.surveymonkey.com/r/Liquibase-Survey-B)
diff --git a/_posts/2019-12-23-liquibase-3-8-4-released.md b/_posts/2019-12-23-liquibase-3-8-4-released.md
deleted file mode 100644
index 16ac00310..000000000
--- a/_posts/2019-12-23-liquibase-3-8-4-released.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.8.4 Released, Corrects Spring Boot Error in Pro
----
-# Liquibase 3.8.4 Released, Corrects Spring Boot Error in Pro
-
-Liquibase 3.8.4 is now available here through [Liquibase.org](https://download.liquibase.org/download-community/).
-The [3.8.4 release is also available on GitHub](https://github.com/liquibase/liquibase/releases/). Here’s a closer look at what's included in the latest release.
-
-## Liquibase 3.8.4 Overview
-
-### Liquibase 3.8.4 Fix for Liquibase Pro Spring Boot Error
-Previously, running a Spring Boot application while using Liquibase 3.8.0+ in Java 9+ caused errors. With the release of Liquibase 3.8.4, users can now use primary workflows with embedded Liquibase cases.
-
-### Bug Fixes
-For both Liquibase Community and Liquibase Pro users, the following bugs were fixed in version 3.8.4:
-- Fixed a 'Class not Found' exception error when using Java +9.
-- Fixed a 'Cannot Use Default Schema Name' error when users diff against an SQL Server snapshot file.
-- Fixed an 'Unexpected type: java.util.Date' error when using a defaultValueDate attribute in a YAML changelog.
-- Improved datetime type handling in SQL Server. Liquibase now preserves types and prevents unexpected behaviors.
-
-### Documentation
-All Liquibase users should also check out our continually improving documentation. For this release, there are several pages with brand new video content! Check them out here:
-- [Creating & Configuring your liquibase.properties File](/documentation/config_properties.html)
-- [Generating SQL to Update Database Schemas](/documentation/generate-sql-update-schemas.html)
-- [Your First Migration with Liquibase Functions](/get_started/quickstart_lb.html)
-
-You can also see our growing library of videos and [subscribe to our YouTube channel](https://www.youtube.com/channel/UC5qMsRjObu685rTBq0PJX8w?).
-
-Full Liquibase documentation is available at [http://www.liquibase.org/documentation/index.html](/documentation/index.html).
diff --git a/_posts/2020-01-06-top-10-findings-liquibase-survey.md b/_posts/2020-01-06-top-10-findings-liquibase-survey.md
deleted file mode 100644
index 5662b85e8..000000000
--- a/_posts/2020-01-06-top-10-findings-liquibase-survey.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Top 10 Findings from Our Liquibase Community Survey
----
-# Top 10 Findings from Our 2019 Liquibase Community Survey
-
-First, a huge THANK YOU to everyone who participated in the Liquibase community survey. We had the best turnout ever and really appreciate all of the great input and feedback. We’ve already adjusted our road map to make sure we are building the features that you are asking for. The system works! Here are the top 10 findings from our survey.
-
-## 1 — Most Liquibase users are developers.
-We’ve learned that most people using Liquibase are coming from development and not from the database side. It’s interesting to understand our users’ backgrounds and what their focus is so that we can help more users get their jobs done easier and faster. Not only that, but it helps us figure out what type of information and analogies might be more useful in the documentation.
-
-
-
-## 2 — Liquibase is used by companies of all sizes.
-It’s fascinating to us to see how well Liquibase can work with different sized teams and for companies both big and small.
-
-
-
-Some of the respondents who opted to have a phone conversation with us have told us that Liquibase works great, but there are pain points around managing complex management tasks for really large deployments. We’re looking into options around what we can offer to help with the ecosystem around Liquibase.
-
-## 3 — Preferences for executing Liquibase are pretty clear.
-Understanding how the community executes Liquibase helps us understand where to invest our time. Maven and the command line are the favorites followed by Spring Boot, and custom shell scripts.
-
-
-
-## 4 — The most popular databases to use with Liquibase surprised us.
-There were some not officially supported (i.e., fully tested and vetted) databases that showed up high on our list and some supported ones that not many people use. It’s definitely time to make sure we’re officially supporting and thoroughly testing the databases the community works with most. We’d like to learn more from you about how you’re using Liquibase with databases like MySQL and MariaDB. Look for a conversation on this topic soon [on our subreddit](https://www.reddit.com/r/liquibase/).
-
-
-
-## 5 — Understanding your preference for writing change scripts.
-We asked the community for their preference for writing change scripts (1 being most preferred and 5 being least preferred). We hear you. Yes, many people like using XML, but many Liquibase users prefer SQL. What many people don't know is that you CAN use plain old SQL with Liquibase. We’ll be focusing on documenting the use of plain SQL better and also improving the overall experience for those that use SQL for change scripts.
-
-
-
-## 6 — Most of you are definitely interested in a centralized dashboard.
-We’ve added creating a dashboard that shows all Liquibase deployments in your organization to our road map! Exciting. We’ll be updating you on our progress here soon.
-
-
-
-## 7 — Most of you are using Jenkins for CI.
-There are a LOT of CI tools out there, but our survey shows most Liquibase users rely on Jenkins. We’d like to begin work on a Jenkins plugin for the community to make it even easier. If you’re interested in using an open source Jenkins plugin for Liquibase, let us know what you’d like to see as part of the plugin. Already make your own version? What should we be aware of? Let us know what you think and [join the discussion on our subreddit](https://www.reddit.com/r/liquibase/comments/ekxhld/jenkins_plugin_for_liquibase_weigh_in/).
-
-
-
-## 8 — We need to continue making our documentation better.
-We’ve made a ton of improvements recently and plan on making many more to our docs, add video tutorials, and make our getting started information more useful. If you haven't seen it lately, [check out the Documentation section](http://www.liquibase.org/documentation/index.html).
-
-Most of the other input we received was about adding or improving integrations and various features. More on that soon.
-
-## 9 — Features that you’d most like to see.
-Features that are highest in demand are around rolling back a specific change and an easier way to run platform-specific SQL. We’ve added these items to our road map and you’ll be seeing these become reality very soon!
-
-## 10 — Overall, you really like Liquibase.
-We received a lot of positive feedback from you. It’s exciting and fun to work on a project so many people love and rely on.
-
-Some positive pieces of feedback we wanted to share:
-
-“We use Liquibase in our CI/CD pipeline with Jenkins and it has worked well for us. We have been using SQL versus XML/JSON/YAML as it allows us to use Postgres BDR and PgLogical features that would otherwise have been unavailable.”
--- Andy K., Senior Software Architect at ACI Worldwide
-
-“I love using Liquibase. I don't want to think about doing database releases without it anymore.”
--- Anonymous
-
-“Liquibase is a great tool that changed the way I managed database changes.”
--- A.F., Development Manager
-
-“Fantastic tool.”
--- Anonymous
-
-Please keep sending feedback about things you wish were better, or submit a documentation pull request. There's a link at the bottom of every page of the site.
\ No newline at end of file
diff --git a/_posts/2020-01-09-liquibase-3.8.5-released.md b/_posts/2020-01-09-liquibase-3.8.5-released.md
deleted file mode 100644
index d931de4a3..000000000
--- a/_posts/2020-01-09-liquibase-3.8.5-released.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.8.5 Released, Many Bug Fixes
----
-# Liquibase 3.8.5 Released, Many Bug Fixes
-
-Liquibase 3.8.5 is now available here through [Liquibase.org](https://download.liquibase.org/download-community/).
-The [3.8.5 release is also available on GitHub](https://github.com/liquibase/liquibase/releases/). Here’s a closer look at what's included in the latest release.
-
-## Liquibase 3.8.5 Bug Fix Overview
-
-We've fixed a number of issues with this release.
-
-### Bug Fixes
-For both Liquibase Community and Liquibase Pro users, the following bugs were fixed in version 3.8.5:
-
-- Fixes issue in which Liquibase did not add `DESC` to an `id` column
-- CLI once again accepts `sqlFile`, `delimiter`, `rollbackScript`, and `outputSchemaAs` arguments
-- Fixes Stored Procedure whitespace impacting update calls
-- Fixes `generateChangelog` failure when there are missing NOT NULL constraints
-- Fixes `updateSQL`, which was not including schemaName for package bodies
-- Fixes bug in which Liquibase was not always capturing `create package body` while generating changeLog
-- Liquibase CLI now gives a more useful error message when an invalid character is passed to a command
-- Fixes an MSSQL issue, which threw an exception when doing diff/diffChangeLog between offline connections (such as when snapshotting json files)
-- Fixes an MSSQL issue, which incorrectly generated `datetime` data type column when using `diff` & `diffChangeLog` Liquibase Maven plugin fails while executing/using "diff" and "generateChangeLog" with PostgreSQL)
-
-## Community Engagement
-We recently shared a [blog about our top findings from our most recent Liquibase Community Survey](https://www.liquibase.org/2020/01/top-10-findings-liquibase-survey.html). Thank you to everyone who participated.
-
-Want to provide more feedback and input? Ready to learn what we're up to? We're having a virtual Liquibase Community Meetup on January 23 with Nathan (Liquibase Project Founder), Steve (Liquibase Community Manager), and Mario (Liquibase Product Manager). Join us. We're looking forward to meeting with you. Register Now.
-
-We are always looking to fix bugs and improve documentation for everyone in the Liquibase community. Here are some ways to contribute:
-- [Contribute code](https://www.liquibase.org/development/contribute.html)
-- [Make doc updates](https://github.com/liquibase/liquibase.github.com/tree/master/documentation)
-
-## More to Explore
-Check out our growing library of videos and [subscribe to our YouTube channel](https://www.youtube.com/channel/UC5qMsRjObu685rTBq0PJX8w?).
-
-Full Liquibase documentation is continually being updated and is available at [https://www.liquibase.org/documentation/index.html](/documentation/index.html). Some of the latest material:
-- [Generating SQL to Update Schemas](http://www.liquibase.org/documentation/generate-sql-update-schemas.html)
-- [DB2 on Z tutorial](https://www.liquibase.org/documentation/tutorials/db2onz.html)
-
diff --git a/_posts/2020-01-28-plain-SQL.md b/_posts/2020-01-28-plain-SQL.md
deleted file mode 100644
index d3d2ee1fc..000000000
--- a/_posts/2020-01-28-plain-SQL.md
+++ /dev/null
@@ -1,137 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-author: Steve Donie
-title: Liquibase Works with Plain Old SQL
----
-# Liquibase Works with Plain Old SQL
-
-It's time for some myth-busting! Yes, Liquibase really can work with SQL scripts. In fact, our [recent Liquibase survey](https://www.liquibase.org/2020/01/top-10-findings-liquibase-survey.html)
-revealed that most of our users prefer using SQL scripts over the other Liquibase changelog options, like XML, JSON, and YAML.
-
-So if you love SQL, here's how you can keep using your SQL scripts AND use Liquibase to automate your database deployments.
-Yes, the first step involves creating an XML changelog, but I promise that you'll be using SQL for all actual changes.
-
-## Create an XML changelog that will house your SQL changesets
-
-{% highlight xml %}
-
-
-
-
-
-
-{% endhighlight %}
-
-Notice the `` tag in the XML example above. Each SQL changelog file that needs to be tracked by Liquibase has to be registered in this XML changelog file.
-Each change will be applied to the database in the order listed in the changelog.
-
-Later on in this post you'll learn about another technique that will use all the files in a given directory.
-
-### Create formatted SQL changelogs
-
-For each change to the database schema, you will need to add the SQL file. While you can use completely plain SQL, there are some additional benefits if you
-add a few select comments to your SQL files. This is referred to as "liquibase formatted SQL". Formatted SQL changelogs look like this:
-
-{% highlight SQL %}
---liquibase formatted sql
---changeset :
-
-
---rollback
---rollback
-
---changeset :
-
-
---rollback
---rollback
-{% endhighlight %}
-
-The first line must always be the comment `--liquibase formatted sql`. This allows typical SQL tools like Oracle sqldeveloper to treat those lines as comments,
-but gives Liquibase a clue that this file is special. The second line starting with `--changeset` is required for each changeset. As with changesets in other
-formats, each changeset must have an author, a unique identifier, and should be an “atomic unit of change".
-
-Real example:
-{% highlight sql %}
---liquibase formatted sql
---changeset stevedonie:create-test-table
-CREATE TABLE testTable(
- columnName1 VARCHAR (355)
-);
---rollback DROP TABLE
---rollback testTable
-{% endhighlight %}
-
-In this example, we purposely made the rollback statement cover multiple lines. When that is the case, you will need to have the `--rollback` comment at the beginning of each line.
-
-Here's an example that demonstrates the ability to have multiple related SQL statements in a single changeset:
-{% highlight sql %}
---liquibase formatted sql
---changeset stevedonie:create-multiple-tables splitStatements:true endDelimiter:;
-create table TEST_1 ( ID int not null, FNAME varchar(100) not null);
-create table TEST_2 ( ID int not null, FNAME varchar(100) not null);
-create table TEST_3 ( ID int not null, FNAME varchar(100) not null);
-create table TEST_4 ( ID int not null, FNAME varchar(100) not null);
-{% endhighlight %}
-
-In this example, notice the `spliStatements:true` addition to the `--changeset` line. This tells Liquibase to split the block of SQL into multiple statements, each of which gets
-executed separately. The `endDelimiter` parameter specifies that the statements should be split on the semicolon character.
-
-Piece of cake!
-
-Now you can rinse and repeat for as many SQL changesets as you'd like. You have a couple of options here for organizing the changesets - you can have multiple changesets in a
-single `.sql` changelog file, and you can also include multiple SQL formatted changelogs in a single XML changelog file.
-
-### Make sure your SQL changelogs are in the XML changelog file
-
-Include the SQL changelog files in the changelog file we created earlier with the following XML tags:
-
-{% highlight xml %}
-
-{% endhighlight %}
-
-Add as many SQL changelogs as you'd like and register them in the changelog file.
-
-### Processing an entire directory with ``
-
-If it seems tedious to both create the .sql file and then add a reference to the file in the XML changelog, there is a way to simplify that. It does require some initial planning though.
-
-Rather than manually adding each sql file you create to the XML changelog, you can instead organize all your SQL into directories, and use the ``
-tag in the changelog to process all of them. When doing this, you will want to have a well-defined naming scheme for the files, because the order that they
-are applied is just alphabetical. One reasonable scheme is to use something like this:
-
-{% highlight text %}
-00000_initial_database_setup.sql
-00010_add_some_tables.sql
-00020_create_some_procedures.sql
-00030_you_can_also_have_xml_changelogs.xml
-{% endhighlight %}
-
-By using an initial five-digit number, the files will get sorted in a predictable order. As people add more changesets, leave some ‘space' in the numbering sequence in
-case you ever need to add a new changeset in between two existing changesets. Notice that you can also include changelogs in other formats.
-
-### Trigger Liquibase to update the database
-
-Our example database is Postgres, but you can use any Liquibase-compatible database. Run the following command to execute Liquibase:
-
-{% highlight bash %}
-liquibase --changeLogFile=/.xml
- --username=
- --password=
- --classpath=/postgresql-42.2.5.jar
- --url=jdbc:postgresql:///
- update
-{% endhighlight %}
-
-## Wrapping up
-
-So there you go — an easy-to-understand way of using SQL that's easy to use in your standard SQL development environment, with the added benefits of tracking them with Liquibase.
-If you're new to Liquibase, try our tutorial: [Your First Migration with SQL.](/get_started/quickstart_sql.html)
-
-For all the details, see the [formatted sql documentation](/documentation/sql_format.html)
-
diff --git a/_scss/_2-col-landing-page.scss b/_scss/_2-col-landing-page.scss
deleted file mode 100644
index a269de6cb..000000000
--- a/_scss/_2-col-landing-page.scss
+++ /dev/null
@@ -1,51 +0,0 @@
-@import "util/_elevation";
-
-.landing-page {
- &__horizontal-rule {
- height: 2px;
- width: 25%;
- background: goldenrod;
- margin-bottom: 24px;
-
- &--centered {
- margin-left: auto;
- margin-right: auto;
- }
- }
-
- &__main-content {
- margin-top: 24px;
- margin-bottom: 48px;
-
- &__heading {
- margin-bottom: 36px;
- }
-
- &__text {
- font-size: 16px;
- margin-bottom: 36px;
- }
-
- &__cta {
- display: inline-block;
- }
- }
-
- &__cta-block {
- @include dat-elevation(2);
- background: whitesmoke;
- padding: 24px;
- border-radius: 6px;
- text-align: center;
- margin-top: 24px;
-
- &__heading {
- margin-bottom: 24px;
- }
-
- &__text {
- font-size: 14px;
- margin-bottom: 24px;
- }
- }
-}
\ No newline at end of file
diff --git a/_scss/_choose-path.scss b/_scss/_choose-path.scss
deleted file mode 100644
index 63face0d6..000000000
--- a/_scss/_choose-path.scss
+++ /dev/null
@@ -1,112 +0,0 @@
-@import "util/_elevation";
-
-.lb-choose-path {
- width: 100%;
- text-align: center;
- margin-bottom: 64px;
-
- p {
- margin-bottom: 0;
- }
-
- &__heading {
- margin-bottom: 48px;
-
- &__title {
- p {
- font-size: 16px;
- }
- }
- }
-
- &__paths {
- display: flex;
- }
-
- &__path {
- display: flex;
- flex-direction: column;
- flex: 1;
- @include dat-elevation(3);
- border-radius: 8px;
- padding: 24px 16px;
- transition: all 0.3s cubic-bezier(0.77, 0, 0.175, 1);
-
- &:hover {
- @include dat-elevation(6);
- transform: translateY(-1px);
- }
-
- &--community {
- margin-right: 24px;
- }
-
- &--pro {
- .lb-choose-path__path__button {
- .cta {
- background: #416692;
- color: white;
- border-color: mix(#416692, #fff, 33%);
- }
- }
- }
-
- &__heading {
- margin-bottom: 24px;
-
- h1,
- h2,
- h3,
- h4,
- h5 h6 {
- margin-bottom: 0;
- }
-
- &__title {
- margin-bottom: 8px;
- }
-
- &__sub-title {
- font-size: 14px;
- }
- }
-
- &__text {
- margin-bottom: 16px;
- font-size: 14px;
-
- p {
- margin: 0;
- }
-
- ul {
- text-align: left;
- }
- }
-
- &__spacer {
- flex-grow: 1;
- }
-
- &__button {
- display: inline-flex;
-
- .cta {
- display: inline-block;
- padding: 6px 12px;
- font-size: 14px;
- text-align: center;
- @include dat-elevation(2);
- transition: box-shadow 0.3s cubic-bezier(0.77, 0, 0.175, 1);
-
- &:hover {
- @include dat-elevation(4);
- }
- }
- }
- }
-
- .cta {
- border: none !important;
- }
-}
diff --git a/_scss/_value-props.scss b/_scss/_value-props.scss
deleted file mode 100644
index 122d59186..000000000
--- a/_scss/_value-props.scss
+++ /dev/null
@@ -1,37 +0,0 @@
-@import "util/_elevation";
-
-h3.value-prop-header {
- text-align: center;
- margin-bottom: calc(1em + 12px);
- font-size: 20px;
-}
-
-.value-prop {
- border-radius: 8px;
- margin-bottom: 36px;
- padding: 24px 16px;
- text-align: center;
- @include dat-elevation(2);
-
- h2 {
- margin-bottom: 24px;
- font-size: 22px;
- }
-
- p {
- margin: auto;
- }
-
- &:nth-of-type(odd) {
- background-color: mix(lightgray, #fff, 13%);
- }
-
- &:nth-of-type(even) {
- background-color: lightgray;
- }
-
- p {
- font-size: 14px;
- max-width: 550px;
- }
-}
diff --git a/_scss/util/_elevation.scss b/_scss/util/_elevation.scss
deleted file mode 100644
index 7e283068a..000000000
--- a/_scss/util/_elevation.scss
+++ /dev/null
@@ -1,113 +0,0 @@
-@function _get-umbra-map($color, $opacity) {
- $shadow-color: if(type-of($color) == color, rgba($color, $opacity * 0.2), $color);
-
- @return (
- 0: '0px 0px 0px 0px #{$shadow-color}',
- 1: '0px 2px 1px -1px #{$shadow-color}',
- 2: '0px 3px 1px -2px #{$shadow-color}',
- 3: '0px 3px 3px -2px #{$shadow-color}',
- 4: '0px 2px 4px -1px #{$shadow-color}',
- 5: '0px 3px 5px -1px #{$shadow-color}',
- 6: '0px 3px 5px -1px #{$shadow-color}',
- 7: '0px 4px 5px -2px #{$shadow-color}',
- 8: '0px 5px 5px -3px #{$shadow-color}',
- 9: '0px 5px 6px -3px #{$shadow-color}',
- 10: '0px 6px 6px -3px #{$shadow-color}',
- 11: '0px 6px 7px -4px #{$shadow-color}',
- 12: '0px 7px 8px -4px #{$shadow-color}',
- 13: '0px 7px 8px -4px #{$shadow-color}',
- 14: '0px 7px 9px -4px #{$shadow-color}',
- 15: '0px 8px 9px -5px #{$shadow-color}',
- 16: '0px 8px 10px -5px #{$shadow-color}',
- 17: '0px 8px 11px -5px #{$shadow-color}',
- 18: '0px 9px 11px -5px #{$shadow-color}',
- 19: '0px 9px 12px -6px #{$shadow-color}',
- 20: '0px 10px 13px -6px #{$shadow-color}',
- 21: '0px 10px 13px -6px #{$shadow-color}',
- 22: '0px 10px 14px -6px #{$shadow-color}',
- 23: '0px 11px 14px -7px #{$shadow-color}',
- 24: '0px 11px 15px -7px #{$shadow-color}'
- );
-}
-
-@function _get-penumbra-map($color, $opacity) {
- $shadow-color: if(type-of($color) == color, rgba($color, $opacity * 0.14), $color);
-
- @return (
- 0: '0px 0px 0px 0px #{$shadow-color}',
- 1: '0px 1px 1px 0px #{$shadow-color}',
- 2: '0px 2px 2px 0px #{$shadow-color}',
- 3: '0px 3px 4px 0px #{$shadow-color}',
- 4: '0px 4px 5px 0px #{$shadow-color}',
- 5: '0px 5px 8px 0px #{$shadow-color}',
- 6: '0px 6px 10px 0px #{$shadow-color}',
- 7: '0px 7px 10px 1px #{$shadow-color}',
- 8: '0px 8px 10px 1px #{$shadow-color}',
- 9: '0px 9px 12px 1px #{$shadow-color}',
- 10: '0px 10px 14px 1px #{$shadow-color}',
- 11: '0px 11px 15px 1px #{$shadow-color}',
- 12: '0px 12px 17px 2px #{$shadow-color}',
- 13: '0px 13px 19px 2px #{$shadow-color}',
- 14: '0px 14px 21px 2px #{$shadow-color}',
- 15: '0px 15px 22px 2px #{$shadow-color}',
- 16: '0px 16px 24px 2px #{$shadow-color}',
- 17: '0px 17px 26px 2px #{$shadow-color}',
- 18: '0px 18px 28px 2px #{$shadow-color}',
- 19: '0px 19px 29px 2px #{$shadow-color}',
- 20: '0px 20px 31px 3px #{$shadow-color}',
- 21: '0px 21px 33px 3px #{$shadow-color}',
- 22: '0px 22px 35px 3px #{$shadow-color}',
- 23: '0px 23px 36px 3px #{$shadow-color}',
- 24: '0px 24px 38px 3px #{$shadow-color}'
- );
-}
-
-@function _get-ambient-map($color, $opacity) {
- $shadow-color: if(type-of($color) == color, rgba($color, $opacity * 0.12), $color);
-
- @return (
- 0: '0px 0px 0px 0px #{$shadow-color}',
- 1: '0px 1px 3px 0px #{$shadow-color}',
- 2: '0px 1px 5px 0px #{$shadow-color}',
- 3: '0px 1px 8px 0px #{$shadow-color}',
- 4: '0px 1px 10px 0px #{$shadow-color}',
- 5: '0px 1px 14px 0px #{$shadow-color}',
- 6: '0px 1px 18px 0px #{$shadow-color}',
- 7: '0px 2px 16px 1px #{$shadow-color}',
- 8: '0px 3px 14px 2px #{$shadow-color}',
- 9: '0px 3px 16px 2px #{$shadow-color}',
- 10: '0px 4px 18px 3px #{$shadow-color}',
- 11: '0px 4px 20px 3px #{$shadow-color}',
- 12: '0px 5px 22px 4px #{$shadow-color}',
- 13: '0px 5px 24px 4px #{$shadow-color}',
- 14: '0px 5px 26px 4px #{$shadow-color}',
- 15: '0px 6px 28px 5px #{$shadow-color}',
- 16: '0px 6px 30px 5px #{$shadow-color}',
- 17: '0px 6px 32px 5px #{$shadow-color}',
- 18: '0px 7px 34px 6px #{$shadow-color}',
- 19: '0px 7px 36px 6px #{$shadow-color}',
- 20: '0px 8px 38px 7px #{$shadow-color}',
- 21: '0px 8px 40px 7px #{$shadow-color}',
- 22: '0px 8px 42px 7px #{$shadow-color}',
- 23: '0px 9px 44px 8px #{$shadow-color}',
- 24: '0px 9px 46px 8px #{$shadow-color}'
- );
-}
-
-// The default opacity scaling value for elevation shadows.
-$dat-elevation-opacity: 1 !default;
-
-// The default color for elevation shadows.
-$dat-elevation-color: black !default;
-
-// Applies the correct css rules to an element to give it the elevation specified by $zValue.
-// The $zValue must be between 0 and 24.
-@mixin dat-elevation($zValue, $color: $dat-elevation-color, $opacity: $dat-elevation-opacity) {
- @if $zValue < 0 or $zValue > 24 {
- @error '$zValue must be between 0 and 24';
- }
-
- box-shadow: #{map-get(_get-umbra-map($color, $opacity), $zValue)},
- #{map-get(_get-penumbra-map($color, $opacity), $zValue)},
- #{map-get(_get-ambient-map($color, $opacity), $zValue)};
-}
diff --git a/about.md b/about.md
deleted file mode 100644
index 5237f7334..000000000
--- a/about.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-layout: default
-title: About Liquibase
-includeDaticalBox: true
----
-
-# About Liquibase #
-Nathan Voxland started the Liquibase project in 2006 to enable easier management of database changes, especially in agile software development environments. It’s open source and licensed under Apache 2.0.
-
-Teams around the world trust Liquibase to easily track and deploy database changes. It’s even been built into solutions such as Spinnaker and Appian.
-
-## Availability ##
-
-**Download Liquibase**
-
-[http://download.liquibase.org](http://liquibase.org/download)
-
-**Official Liquibase Maven groups**
-
-[org.liquibase](http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.liquibase%22) and
-[org.liquibase.ext](http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.liquibase.ext%22)
-
-**Main Liquibase artifact**
-
-[group:org.liquibase, artifact:liquibase-core](http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22liquibase-core%22)
-
-## Source Code ##
-
-All source code managed as part of the Liquibase project is available at [https://github.com/liquibase](https://github.com/liquibase)
-
-The main Liquibase code is at [https://github.com/liquibase/liquibase](https://github.com/liquibase/liquibase)
-
-## License ##
-
-Liquibase is [licensed under the Apache 2.0 License](https://github.com/liquibase/liquibase/blob/master/LICENSE.txt)
-
-Liquibase Pro, with additional features and support, is [commercially licensed](https://download.liquibase.org/eula/).
-
-LIQUIBASE is a registered trademark of [Datical](https://www.datical.com).
-
-## Friends of Liquibase ##
-
-The following companies provide software and/or services to help support Liquibase:
-
-- **Datical** (Sponsors Liquibase Development [https://www.datical.com](https://www.datical.com/))
-- **Atlassian** (Provides [http://liquibase.jira.com](http://liquibase.jira.com))
-- **Zoho** (Provides [http://forum.liquibase.org](http://forum.liquibase.org))
-- **YourKit** (Provides [Java Profiler](http://yourkit.com))
diff --git a/apache_derby.html b/apache_derby.html
deleted file mode 100644
index 665c5b85a..000000000
--- a/apache_derby.html
+++ /dev/null
@@ -1,7 +0,0 @@
-
-
-
-
- Redirecting to /documentation/tutorials/apache-derby.html...
-
-
diff --git a/atom.xml b/atom.xml
deleted file mode 100644
index 7ce18cc2f..000000000
--- a/atom.xml
+++ /dev/null
@@ -1,28 +0,0 @@
----
-layout: null
----
-
-
-
-
- {{ site.title }}
-
-
- {{ site.time | date_to_xmlschema }}
- {{ site.url }}
-
- {{ site.author.name }}
- {{ site.author.email }}
-
-
- {% for post in site.posts %}
-
- {{ post.title }}
-
- {{ post.date | date_to_xmlschema }}
- {{ site.url }}{{ post.id }}
- {{ post.content | xml_escape }}
-
- {% endfor %}
-
-
\ No newline at end of file
diff --git a/bestpractices.md b/bestpractices.md
deleted file mode 100644
index fee084b7c..000000000
--- a/bestpractices.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-layout: default
-title: Docs | Best Practices
-includeDaticalBox: true
----
-
-# Liquibase Best Practices #
-This page describes a number of best practices that you can apply on your project.
-
-## Organizing your changeLogs ##
-The most common way to organize your changelogs is by major release. Choose a package in your classpath to store the changelogs, preferably near your database access classes. In this example, we will use com/example/db/changelog
-
-### Directory Structure ###
-
-{% highlight text %}
- com
- example
- db
- changelog
- db.changelog-master.xml
- db.changelog-1.0.xml
- db.changelog-1.1.xml
- db.changelog-2.0.xml
- DatabasePool.java
- AbstractDAO.java
-{% endhighlight %}
-
-
-### db.changelog-master.xml ###
-
-The master.xml includes the changelog for the releases in the correct order. In the example above it could look like this:
-
-{% highlight xml %}
-
-
-
-
-
-
-
-{% endhighlight %}
-
-Each of the included XML files needs to be in the same format as a standard XML database change log, something like this:
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-The db.changelog-master.xml is the changelog you pass to all Liquibase calls.
-
-### Managing Stored Procedures ###
-
-Try to maintain separate changelog for Stored Procedures and use runOnChange="true". This flag forces LiquiBase to check if the changeset was modified. If so, liquibase executes the change again.
-
-### One Change per ChangeSet ###
-
-As far as possible, Avoid multiple changes per changeset to avoid failed autocommit statements that can leave the database in an unexpected state.
-
-## ChangeSet Ids ##
-
-Choose what works for you. Some use a sequence number starting from 1 and unique within the changelog, some choose a descriptive name (e.g. 'new-address-table').
-
-## Document ChangeSets ##
-
-Use `` in the change sets. They say "A stitch in time saves nine!"
-
-## Always think about rollback ##
-
-Try to write changesets in a way that they can be rolled back. e.g. use relevant change clause instead of using custom `` tag.
-Include a `` clause whenever a change doesn't support out of box rollback. (e.g. ``, ``, etc)
-
-## Reference Data Management ##
-
-Leverage Liquibase to manage your Reference Data. Environment separation (DEV, QA, PROD) can be achieved using "context".
-
-## Procedure for the developer ##
-
-* Using your favorite IDE or editor, create a new local changeSet containing the change;
-* Run Liquibase to execute the new changeSet (this tests the SQL code);
-* Perform the corresponding changes in the application code (e.g., Java code);
-* Test the new application code together with the database change;
-* Commit both the changeSet and the application code.
-
-## Consider Liquibase Pro or Datical ##
-
-### Liquibase Pro ###
-Liquibase Pro offers an extra layer of support so you don't have to go it alone. While Liquibase is a great starting point, teams that want best practices on how to make the most of Liquibase may find Liquibase Pro better suited to their needs. Liquibase Pro also adds functions for procedural database code.
-
-### Datical ###
-Datical is a commercial product which builds on the core Liquibase functionality. Beyond versioning and managing database changes, Datical bridges the gap between development and operations with capabilities that enable a fully unified and automated path for database code.
-
-* Datical has a web interface, command line interface, and REST API. All interfaces are secure and require authentication.
-* Datical automatically verifies database code against organizational standards to eliminate manual review
-* Datical automatically generates changesets from validated DDL code, eliminating manual effort in crafting changesets and manually updating the changelog
-* Datical generates an immutable artifact for database code for consistent, repeatable, and automation-ready downstream deployments
-* Datical forecasts the impact of database changes with an object-based model of the target database to ensure that there are no errors or issues when deploying database changes
-* Datical integrates with ticketing systems such as JIRA to make it easy to trace database changes back to source code and initial requirements. This same capability also makes it easy to hold or accelerate feature sets.
-* Datical can snapshot and compare database schemas to help identify and address drift
-
-For more information on Datical, visit https://www.datical.com/Liquibase
-
-
diff --git a/blog/images/Jenkins-preference-Liquibase.png b/blog/images/Jenkins-preference-Liquibase.png
deleted file mode 100644
index 2d7d8f7f8..000000000
Binary files a/blog/images/Jenkins-preference-Liquibase.png and /dev/null differ
diff --git a/blog/images/apt-get-candy.png b/blog/images/apt-get-candy.png
deleted file mode 100644
index 1e1b216b9..000000000
Binary files a/blog/images/apt-get-candy.png and /dev/null differ
diff --git a/blog/images/authoring-database-change-scripts.png b/blog/images/authoring-database-change-scripts.png
deleted file mode 100644
index 0a2880918..000000000
Binary files a/blog/images/authoring-database-change-scripts.png and /dev/null differ
diff --git a/blog/images/company-size-employees.png b/blog/images/company-size-employees.png
deleted file mode 100644
index 9934483db..000000000
Binary files a/blog/images/company-size-employees.png and /dev/null differ
diff --git a/blog/images/dashboard-interest.png b/blog/images/dashboard-interest.png
deleted file mode 100644
index de7b54c12..000000000
Binary files a/blog/images/dashboard-interest.png and /dev/null differ
diff --git a/blog/images/dba-and-rm.png b/blog/images/dba-and-rm.png
deleted file mode 100644
index 482266cc3..000000000
Binary files a/blog/images/dba-and-rm.png and /dev/null differ
diff --git a/blog/images/execute-liquibase.png b/blog/images/execute-liquibase.png
deleted file mode 100644
index a9351b920..000000000
Binary files a/blog/images/execute-liquibase.png and /dev/null differ
diff --git a/blog/images/job-title-role.png b/blog/images/job-title-role.png
deleted file mode 100644
index 945115939..000000000
Binary files a/blog/images/job-title-role.png and /dev/null differ
diff --git a/blog/images/pin-procedure.png b/blog/images/pin-procedure.png
deleted file mode 100644
index 6d2d9340b..000000000
Binary files a/blog/images/pin-procedure.png and /dev/null differ
diff --git a/blog/images/popular-databases-liquibase.png b/blog/images/popular-databases-liquibase.png
deleted file mode 100644
index 9779da86f..000000000
Binary files a/blog/images/popular-databases-liquibase.png and /dev/null differ
diff --git a/blog/images/survey-2018-doc-helpful.png b/blog/images/survey-2018-doc-helpful.png
deleted file mode 100644
index b6df4f6be..000000000
Binary files a/blog/images/survey-2018-doc-helpful.png and /dev/null differ
diff --git a/blog/images/survey-2018-extension-use.png b/blog/images/survey-2018-extension-use.png
deleted file mode 100644
index 993278b59..000000000
Binary files a/blog/images/survey-2018-extension-use.png and /dev/null differ
diff --git a/blog/images/survey-2018-group-size-dev.png b/blog/images/survey-2018-group-size-dev.png
deleted file mode 100644
index b347378d8..000000000
Binary files a/blog/images/survey-2018-group-size-dev.png and /dev/null differ
diff --git a/blog/images/survey-2018-group-size-it.png b/blog/images/survey-2018-group-size-it.png
deleted file mode 100644
index 6c0bc5ded..000000000
Binary files a/blog/images/survey-2018-group-size-it.png and /dev/null differ
diff --git a/blog/images/survey-2018-meet-needs.png b/blog/images/survey-2018-meet-needs.png
deleted file mode 100644
index 26fcee5cf..000000000
Binary files a/blog/images/survey-2018-meet-needs.png and /dev/null differ
diff --git a/blog/images/survey-2018-projects.png b/blog/images/survey-2018-projects.png
deleted file mode 100644
index 4fd43ed35..000000000
Binary files a/blog/images/survey-2018-projects.png and /dev/null differ
diff --git a/blog/images/survey-2018-who-uses.png b/blog/images/survey-2018-who-uses.png
deleted file mode 100644
index 82d88b331..000000000
Binary files a/blog/images/survey-2018-who-uses.png and /dev/null differ
diff --git a/blog/index.html b/blog/index.html
deleted file mode 100644
index 0ca27d5f5..000000000
--- a/blog/index.html
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: default
-title: Liquibase Blog
-subnav: subnav_blog.md
----
-
-
- Using Liquibase to Achieve CI/CD for Databases
-
-
-
-
Application release technology has come a long way in the past several years. It used to take weeks or even months to release new software. Now that organizations have adopted new workflows and processes, the time it takes to complete a release has been reduced to days and even hours. It’s an exciting time. However, there is one area that hasn’t benefited from the DevOps movement as much. The database change process isn’t nearly as automated or as fast as app code changes.
-
Database Schema Migration
-
Database schema migrations are an essential task for every software project. There are several different reasons why updates to the database are required, some examples are:
-
-
New features require new attributes in existing tables or entirely new tables
-
Bug fixes may lead to changes in names or data types in the database
-
Performance issues that require additional indexes in the database
-
-
-
Even in organizations that have adopted DevOps, manual rework is the norm when it comes to database schema and stored procedure changes.1 In fact, the faster the application release cycle, the more database professionals had to rework database changes. 93% of survey respondents reported reworking database changes multiple times for daily or weekly release cycles.1
-
Understanding CI/CD
-
Before we jump into how Liquibase fits into the CI/CD process, let’s cover what we mean by CI/CD.
-
What is Continuous Integration (CI)?
-
Continuous integration (CI) is a process that automates the integration of code changes from multiple developers a single software project. The CI process hinges on a source code version control system, such as Git (or Github, BitBucket, and many others) or TFS Version Control, coupled with automated processes for code quality tests, syntax style review tools, and more. These processes can be triggered when new code is merged or committed to a shared repository, thus the name “Continuous Integration.”
-
What is Continuous Deployment (CD)?
-
Continuous Deployment (CD) is a process that automates testing to validate if code changes are correct, stable and deployable. If so, in a literal CD context, code is automatically deployed to production as soon as these conditions are met.
-
CI/CD for Databases Using Liquibase
-
Implementing end-to-end CI/CD requires all code (including database code) to be checked in to a version control system and be deployed as part of the software release process. Liquibase can help you achieve this.
-
Each database schema change you make with Liquibase is called a “changeset.” All changesets are tracked by Liquibase using changelogs. Liquibase allows you to create a trigger that updates the database automatically by pointing to the changelog file. From here, it makes it easy to integrate the process into your overall CI/CD process:
-
-
Push your changeset files to your feature repository
-
Create a pull request against the Dev branch
-
After peer review and approvals, merge the feature branch with the Dev branch
-
The CI/CD implementation configured on the Dev server triggers Liquibase for database updates
-
Liquibase automatically executes any new changelog files (and is awesome enough to remember which scripts have already run)
-
-
Three Ways to Integrate Databases into Your CI/CD Process
-
Companies have software teams of all shapes, sizes, and types. These teams may run anything from huge mission-critical databases to newer NoSQL databases. The one thing that every team has in common is the need for a process to handle database version control and changes to ensure that applications deploy quickly and without errors.
-
Since each software team is different, it makes sense for organizations to choose the right database change management solution based on team makeup, the complexity of the database, how frequently it needs to be updated, and the importance of applications it supports.
-
Track, Version and Deploy Database Changes
-
Liquibase offers products at three levels to help increase productivity for every software team’s use case.
-
Liquibase Community
-
Open source and always free
-
Liquibase provides a great starting point for teams addressing the challenges that come with managing database changes. Founded over a decade ago, Liquibase is the leading open source solution for helping teams track, version, and deploy database changes. It has been downloaded over 12 million times by teams around the world and is built into solutions such as Spinnaker and Appian. It’s simple enough for beginners and powerful enough to support advanced use cases that involve reworking database changes.
-
-
Track, version, deploy, and rework database changes
Liquibase Pro adds more features to Liquibase’s powerful database change control capabilities, including targeted rollbacks and the ability to track, version, and deploy Store Logic.
-
While Liquibase is a great starting point, teams that want best practices on how to make the most of Liquibase may find Liquibase Pro better suited to their needs.
-
-
Targeted rollbacks
-
Track, version, and deploy Stored Logic
-
Guidance and best practices for your specific use case(s)
A comprehensive solution with enterprise features and world-class support
-
Datical enhances the database change management experience with access to advanced capabilities such as automatic enforcement of predefined DBA rules (improving productivity), a simulator that forecasts the impact of database changes before they are deployed (reducing risk and eliminating downtime), and a dashboard that automates tracking and reporting of every database deployment (simplifying audits).
-
Datical provides more than just software; it offers built-in, consultative implementation assistance and support that gets teams to database release automation success faster with lower risk.
-
We partner with your whole team to ensure your mission-critical database changes are deployed safely and seamlessly.
- {% include components/buttons/cta.html ctaText="Try Liquibase Pro Free for 30 Days" ctaHref="https://download.liquibase.org/liquibase-pro-trial-request-form/" %}
-
-
-
-
-
-
- Take Liquibase Pro for a spin!
-
-
-
-
- Get a free 30-day trial of Liquibase Pro. If you decide you don't want the Pro features, simply keep using the open source version.
-
-
-
- {% include components/buttons/cta.html ctaText="Try Liquibase Pro" ctaHref="https://download.liquibase.org/liquibase-pro-trial-request-form/" %} No credit card required.
-
ASE 12.0+ required. "select into" database option needs to be set. Best driver is JTDS. Sybase does not support transactions for DDL so rollbacks will not work on failures. Foreign keys can not be dropped which can break the rollback or dropAll functionality.
-
-As of Liquibase v3.1, support for some less common databases has been moved out of Liquibase core and into extensions.
-
-To re-enable support for these databases, install the corresponding extension:
-
-- InterSystems Cache
-- SAP MaxDB
-- IBM DB2 for iSeries
-
-# Using Unsupported Databases #
-
-Since Liquibase is built on top of standard JDBC, the only ties it has to the underlying database is through the SQL that can vary from DBMS to DBMS. If you attempt to use Liquibase with an unsupported database, it will try to run and will most likely succeed. The only problem you are likely to run into is the current date/time function name. If Liquibase is unable to determine the correct date/time function, you can pass it in via the ["command line"](documentation/command_line.html) and [documentation/Ant](documentation/ant/index.html)).
-
-You may also run into problem with the SQL generated by the change/refactoring tags on unsupported databases. The best way to deal with this problem is to first try the standard change/refactoring tags. If it generates an error, you can fall back to the [sql change](documentation/changes/sql.html) to code whatever change you need to make in a way that your database understands.
-
-If, for some reason, the DatabaseChangeLog table cannot be created on your database, the base creation SQL that you can modify to suit your needs is:
-
-{% highlight sql %}
-CREATE TABLE DATABASECHANGELOG (id varchar(150) not null,
-author varchar(150) not null,
-filename varchar(255) not null,
-dateExecuted datetime not null,
-md5sum varchar(32),
-description varchar(255),
-comments varchar(255),
-tag varchar(255),
-liquibase varchar(10),
-primary key(id, author, filename))
-{% endhighlight %}
-
-Reasons for creating the DatabaseChangeLog table yourself include database that require null fields to be specified as such and index limitations that don't allow primary keys on fields as long. You can change the data types and or data type lengths all you want.
diff --git a/dba.md b/dba.md
deleted file mode 100644
index 4579ff494..000000000
--- a/dba.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-layout: default
-title: Liquibase for DBAs
----
-
-# Liquibase for DBAs #
-
-### No change is forgotten
-
-Liquibase [tracks which changelog statements](documentation/databasechangelog.html) have run against each database, so you no longer have to manually track what statements have been run against each database and which have not.
-
-### Like SQL? Use SQL
-
-XML-formatted changelogs have their advantages, but many DBAs still prefer good, old fashioned SQL. If that is what you are most comfortable working with, [Liquibase-formatted SQL](documentation/sql_format.html) gives you the standard changeSet tracking used in any changelog format, but lets you specify the exact SQL you want.
-
-### Manually verify the database changes with each release
-
-Liquibase supports an ["updateSql"](documentation/sql_output.html) command which will not actually update the database, but instead output the SQL that will run. That script can be read through and verified to ensure everything is correct and doing what it is supposed to.
-
-After you know everything is correct, you can either run liquibase update, or run your script through your favorite tools. The script will include the [DATABASECHANGELOG](documentation/databasechangelog_table.html) inserts so everything will still be correctly tracked.
-
-### Prepare for deployment problems
-
-Releases don't always go as planned, and so Liquibase lets you ensure your contingency plans are correct before each release. As you near a release, besides checking the updateSql output, you can also run [futureRollbackSql](documentation/rollback.html) which will output the SQL needed to bring a fully updated database back to the current state. It will be much less stressful verifying the rollback logic BEFORE the release.
-
-### A unified changelog for all your databases
-
-You try to keep all your databases the same, but there are always differences. QA needs test data, production gets a couple extra tables, and the hot-backup server needs extra configuration. Liquibase supports contexts, labels, parameters, and preconditions that let you address minor differences in your scripts to adjust things as needed.
-
-* [Contexts](/documentation/contexts.html) and labels let you target certain changeSets to run in only some environments.
-* [Parameters](/documentation/changelog_parameters.html) let you do simple text substitutions when things like schema names vary from database to database.
-* [Preconditions](/documentation/preconditions.html) let you check the state of the database to dynamically determine if a changeSet should be executed or not.
-
-Thanks to Liquibase's [cross-database support](/databases.html, you can even use a single changelog that supports Oracle, MS SqlServer, Postgresql, and more.
-
-### Enterprise features with Datical
-
-Beyond all the standard Liquibase functionality, Datical lets you
-
-* [Package database schema changes](http://www.datical.com/product/packaging-intelligence/) alongside application code
-* Simulate deployments to [forecast potential errors](http://www.datical.com/product/validation-intelligence/)
-* [Know the deployment status](http://www.datical.com/product/management-intelligence/) of every schema in the database
-* Integrate with popular [DevOps tools](http://www.datical.com/integrations/)
-
-
----
-
-Liquibase for [QA](/qa.html) \| [Developers](/developer.html) \| [Release Managers](/release_manager.html)
\ No newline at end of file
diff --git a/dbdoc/authors.html b/dbdoc/authors.html
deleted file mode 100644
index a73c02f72..000000000
--- a/dbdoc/authors.html
+++ /dev/null
@@ -1,19 +0,0 @@
----
-layout: default
----
-
- All Authors
-
-
-
\ No newline at end of file
diff --git a/dbdoc/authors/alan.html b/dbdoc/authors/alan.html
deleted file mode 100644
index 62f31153f..000000000
--- a/dbdoc/authors/alan.html
+++ /dev/null
@@ -1,36 +0,0 @@
-Changes created by author alan
Generated By: LiquiBase 1.3.3
\ No newline at end of file
diff --git a/dbdoc/authors/bjohnson.html b/dbdoc/authors/bjohnson.html
deleted file mode 100644
index 83d79705a..000000000
--- a/dbdoc/authors/bjohnson.html
+++ /dev/null
@@ -1,64 +0,0 @@
-Changes created by author bjohnson
Generated By: LiquiBase 1.3.3
\ No newline at end of file
diff --git a/dbdoc/authors/nvoxland.html b/dbdoc/authors/nvoxland.html
deleted file mode 100644
index 0ba335a76..000000000
--- a/dbdoc/authors/nvoxland.html
+++ /dev/null
@@ -1,828 +0,0 @@
-Changes created by author nvoxland
You can add comments to changeSets.
- They can even be multiple lines if you would like.
- They aren't used to compute the changeSet MD5Sum, so you can update them whenever you want without causing
- problems.
Generated By: LiquiBase 1.3.3
\ No newline at end of file
diff --git a/dbdoc/authors/pkeeble.html b/dbdoc/authors/pkeeble.html
deleted file mode 100644
index 524b3dce7..000000000
--- a/dbdoc/authors/pkeeble.html
+++ /dev/null
@@ -1,22 +0,0 @@
-Changes created by author pkeeble
You can add comments to changeSets.
- They can even be multiple lines if you would like.
- They aren't used to compute the changeSet MD5Sum, so you can update them whenever you want without causing
- problems.
You can add comments to changeSets.
- They can even be multiple lines if you would like.
- They aren't used to compute the changeSet MD5Sum, so you can update them whenever you want without causing
- problems.
Generated By: LiquiBase 1.3.3
\ No newline at end of file
diff --git a/developer.md b/developer.md
deleted file mode 100644
index bf511d9cf..000000000
--- a/developer.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-layout: default
-title: Liquibase for Developers
----
-
-# Liquibase for Developers #
-
-### Store your database changes with your code
-
-Your database schema is an integral part of your application, so store your changelog files along side your application code. That will allow your existing version control system to ensure everything is kept in sync--whenever you commit your code your database changes will go with it and whenever anyone updates their code they will get the new database schema.
-
-### Supports branches
-
-Branches are an integral part of developing code and your database changes need to flow along with them. Because Liquibase tracks each changeSet independently rather than relying on a single incrementing "database version", when you merge in a branch all the new changeSets will execute as expected, even if there were "later" changeSets already executed.
-
-When you do run into merge issues, the simple text formats used for the changelog files can be easily merged with your favorite tools.
-
-### Author changeSets in your favorite markup
-
-Liquibase supports changelogs written in XML, YAML, JSON and SQL. Use whatever is most readable to you
-
-### Know that your changes will not get forgotten down the line
-
-Liquibase [tracks which changelog statements](documentation/databasechangelog.html) have run against each database, so once you create a changeSet you can be confident that it will be deployed through QA and production.
-
-For best results, append a new changeSets as needed then run liquibase update to apply it to your local database. This works better than making changes to your database directly and then re-writing it as a changeSet because you are truly running the same update as everyone else will.
-
-### Like SQL? Use SQL
-
-XML-formatted changelogs have their advantages, but many DBAs still prefer good, old fashioned SQL. If that is what you are most comfortable working with, [Liquibase-formatted SQL](documentation/sql_format.html) gives you the standard changeSet tracking used in any changelog format, but lets you specify the exact SQL you want.
-### Easier test data management
-
-Normally, test data is stored in something like CSV files which are loaded into the database after it is built. The problem with this strategy is that any schema changes will usually break in your data load process, leading to hours of time spent figuring out what the test data was trying to expose and then adjusting the files to match the new schema.
-
-Instead of loading the data into the final schema, build up your test data within your changelog file. Use [loadData](/documentation/changes/load_data.html) or standard [sql](/documentation/changes/sql.html) to load data into the schema as it is now, then as new schema changes are appended to the changelog your test data will be migrated just like production data would be. This not only keeps you from having to continually update your CSV files, but also helps verify that existing data is handled correctly.
-
-Use [contexts](/documentation/contexts.html) and labels to mark which changeSets contain test data so they are not deployed to production.
-
-### Sanity checks
-
-Liquibase ships with several tools you can use to make sure changes are being applied correctly, check current database state, and that nobody is sneaking in changes out of process.
-
-* The status and validate commands report on what changeSets have not yet been ran and checks the changelog for errors.
-* The [diff](/documentation/diff.html) command reports on differences between databases to ensure that two fully updated databases are truly identical
-* The [dbdoc](/documentation/dbdoc.html) command generates documentation on the current database structure and its changes over time
-
-### Enterprise features with Datical
-
-Beyond all the standard Liquibase functionality, Datical lets you
-
-* [Package database schema changes](http://www.datical.com/product/packaging-intelligence/) alongside application code
-* Simulate deployments to [forecast potential errors](http://www.datical.com/product/validation-intelligence/)
-* [Know the deployment status](http://www.datical.com/product/management-intelligence/) of every schema in the database
-* Integrate with popular [DevOps tools](http://www.datical.com/integrations/)
-
-
----
-
-Liquibase for [DBAs](/dba.html) \| [QA](/qa.html) \| [Release Managers](/release_manager.html)
diff --git a/development/architecture.md b/development/architecture.md
deleted file mode 100644
index dcd5e7742..000000000
--- a/development/architecture.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-layout: default
-title: Docs | Architecture
----
-
-# Liquibase Architecture #
-
-The Liquibase migrator is designed to require no dependencies to run and be easy to integrate into various build and deployment processes.
-
-The primary worker class for Liquibase is [liquibase.Liquibase](http://www.liquibase.org/api/liquibase/Liquibase.html). All the various ways of interacting with Liquibase ([command line](http://www.liquibase.org/api/liquibase/commandline/CommandLineFileOpener.html), [Ant](http://www.liquibase.org/api/liquibase/ant/DatabaseMigratorTask.html), etc.) are thin wrappers around the Liquibase class.
-
-Each database refactoring/change is implemented by a class in the [liquibase.change](http://www.liquibase.org/api/liquibase/change/package-summary.html) package. As the Liquibase migrator runs, it uses a SAX XML parser to parse the change logs, instantiate the necessary change class, and run or save the corresponding SQL.
-
-If you have additional questions about Liquibase's architecture, please contact us via the [mailing list](../community/index.html).
diff --git a/development/branches.md b/development/branches.md
deleted file mode 100644
index 496eed747..000000000
--- a/development/branches.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: default
-title: Docs | Liquibase Code Branches
----
-
-# Liquibase Code Branch Strategy #
-
-Liquibase uses a branching strategy using the following long-lived branches:
-
-* master: Corresponds to the next non-patch release in progress
-* "#.#.x". Each non-patch release such as "3.1" gets a branch for itself and its patch releases. For example, the 3.1.0 release will be the start of the "3.1.x" branch
-
-Individual features and bug fixes should be developed in their own short-lived feature branches with a pull request to incorporate them into the main repository branches.
-For more information on pull requests and GitHub usage, see [contributing to Liquibase](contribute.html).
-
-As part of each release, the releasing branch will be tagged with the actual version number and the changes will be merged into all downstream branches.
-
-### Which branch do I use?
-
-When working on a bug or feature, the code should based off the branch corresponding to the furthest back version family that will include the change.
-
-So if you are ok with the change only going into the next release, branch off "master". If you are using version 3.0.2 and need the change in an upcoming 3.0 patch release, branch off "3.1.x".
-
-If you have questions, [help is available](../community/index.html).
-
-
-
-### Example Workflow
-
-Starting state: there are 3 active branches: "master", "3.0.x", and "3.1.x". 3.0.3 and 3.1.2 are the most recent releases in the previous release families.
-
-Because 3.1 has been released, most development is occurring off the "master" branch. Features are developed in fork branches off "master" and when they are done, pull requests are created and accepted into master.
-
-If a bug is found that needs to be fixed in a 3.1, it is worked on in a branch off 3.1 and when it is done a pull request is created and accepted into the 3.1.x branch.
-
-When we are ready to have a 3.1.3 release, the 3.1.x branch is tagged as "3.1.3" and then merged into "master".
-
-When we are ready to release the code in "master" and a version number is decided on such as 3.2, a "3.2.x" branch is created for final testing and tagged as "3.2.0" at release time.
-
diff --git a/development/building.md b/development/building.md
deleted file mode 100644
index d4a8bcfe3..000000000
--- a/development/building.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-layout: default
-title: Docs | Building Liquibase
----
-
-# Building Liquibase
-
-Liquibase is built using Maven 3. There is a top-level Maven pom.xml file in the root directory which will build each of the sub-modules in turn.
-3rd party jar dependencies are configured within the Maven pom.xml files and are automatically downloaded as part of the build process.
-
-## Build Requirements
-
-* Java SE JDK 1.8 or higher installed
-* Maven 3.0 or higher
-* No OS requirements
-
-## Running Maven
-
-1. Download maven 3.0 or greater from [maven.apache.org](http://maven.apache.org)
-1. Unzip maven wherever you prefer
-1. `cd ROOT_LIQUIBASE_SOURCE_DIR`
-1. `/MAVEN_HOME/bin/mvn package`
-
-Build output goes to the "target" directory under each top level directory. The standard liquibase core jar file is in `ROOT_LIQUIBASE_SOURCE_DIR/liquibase-core/target/liquibase-VERSION.jar`
-
-**Note: If you prefer to build Liquibase without running the tests, run `/MAVEN_HOME/bin/mvn -DskipTests=true package`**
diff --git a/development/code_org.md b/development/code_org.md
deleted file mode 100644
index 10c3ad84a..000000000
--- a/development/code_org.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-layout: default
-title: Docs | Architecture
----
-
-# Liquibase Code Organization
-
-## Repository Structure
-
-All Liquibase code is accessible from [github.com/liquibase](http://github.com/liquibase).
-
-The [github.com/liquibase/liquibase](http://github.com/liquibase/liquibase) repository contains the core Liquibase library. This includes:
-
-* Code for supported Databases
-* Standard Change/Refactoring code
-* Code for running Liquibase through the command prompt, Ant, Maven, a servlet container, and Spring.
-* Code for parsing and writing XML, YAML, JSON, and SQL changelog formats
-
-From [github.com/liquibase](http://github.com/liquibase) you can also access the code for Liquibase-managed extensions such as [github.com/liquibase-mssql](http://github.com/liquibase/liquibase-mssql)
-
-### Liquibase Core vs. Liquibase Extensions
-
-Liquibase is designed to be a small core of functionality that will work in a standard way across all database types, but with the ability to extend, enhance and even replace that functionality as needed.
-More information about writing extensions can be found at the [extension portal](../extensions/index.html).
-
-We take advantage of that design even with our code by keeping database-specific functionality and non-common logic in extensions rather than continuing to add additional modes and flags to the base library.
-For example, there is not support for managing packages and triggers across all database types, but if we want to introduce that support for Oracle we can create a liquibase-oracle extension that supports that.
-Similarly, if want to provide a way to ignore all checksums, rather than build that potentially bad practice into the main codebase we will create an extension.
-
-There is a fine line sometimes between what should go in core and what should be an extension, and features do migrate in and out of core as well. If you have questions on where functionality is or should go,
-you can always [use the developer forums](../community/index.html).
-
-## Top level Directory Structure
-
-The main Liquibase repository contains 4 top level directories to divide the codebase
-
-1. **liquibase-core** contains all code for the standard Liquibase functionality
-1. **liquibase-integration-tests** contains only tests that actually run against databases.
-1. **liquibase-maven-plugin** contains code for Maven support.
-1. **liquibase-osgi** contains an osgi compatible BundleActivator for Liquibase
-
-## Project configurations(s)
-
-Liquibase uses Maven as its build system, with pom files corresponding to each of the top level directories, plus a "parent" pom in the root directory.
-Dependencies between top-level directories and 3rd party jar files can be found within the maven pom.xml files.
-
-For those using IntelliJ IDEA, there there is a project configuration in .idea directory format as part of the repository.
-The intellij config is built directly from the maven projects.
-
-For those using Eclipse, you can automatically create your project config from the Maven pom.xml files.
-
-## General Module Code Structure
-
-Each of the top-level directories/modules follows the standard maven source layout with a "src" dir containing both a "main" and a "test" directory.
-Within both main and test, there is a "java" directory which contains the java code and a "resources" directory for non-source code files.
-
-## Liquibase-Core Code Structure
-
-In the liquibase-core module, all code exists under the "liquibase" package.
-There is a second-level package for each of the major code units withing Liquibase such as "liquibase.change" and "liquibase.parser".
-
-Because most packages support extensions, you will normally find a \*Factory class which loads the available classes. Each package will normally have a "core" 3rd level package that contains the built-in standard functionality.
-Interfaces and other classes needed for given feature are generally within the second level package.
-
-For example:
-
-* The liquibase-core/src/main/java/liquibase/change directory contains all "change" related logic
-* liquibase/change contains ChangeFactory.java which will find all available Change implementations.
-* liquibase/change contains Change.java, AbstractChange.java, CheckSum.java and other classes used by core and extension Change classes.
-* There is a liquibase-core/src/main/java/liquibase/change/core directory which contains all the built-in Change implementations such as CreateTableChange.java and DropViewChange.java
-
-For more information, see the [javadoc](../javadoc/index.html) or [check out the code](http://github.com/liquibase/liquibase).
diff --git a/development/contribute.md b/development/contribute.md
deleted file mode 100644
index 83f3e801b..000000000
--- a/development/contribute.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-layout: default
-title: Docs | Contributing to Liquibase
----
-
-# Contributing to Liquibase #
-
-## Using GitHub ##
-
-Liquibase uses the typical GitHub pull request workflow. GitHub provides great documentation including [How to Fork a Repository](https://help.github.com/articles/fork-a-repo) and [Using Pull Requests](https://help.github.com/articles/using-pull-requests).
-
-The root Liquibase repository is at [http://github.com/liquibase/liquibase](http://github.com/liquibase/liquibase). To contribute fixes and features:
-
-1. Create a fork of the main repository using the "Fork" button in the GitHub web interface
-1. Clone your new repository to your computer
-1. Create a branch in your repository for the fix or feature you are going to contribute
-1. Code and test until done
-1. Using git, "push" your changes back up to your local GitHub repository
-1. Create a pull request in the GitHub web interface
-1. Participate in any discussion on the pull request
-
-## Git crash course ##
-
-If you have not used Git or GitHub before, there are many resources available including [Git - SVN Crash Cource](http://git.or.cz/course/svn.html) and the general [GitHub Help](http://help.github.com).
-
-If you would prefer to use subversion, GitHub [transparently supports SVN clients as well](https://github.com/blog/1178-collaborating-on-github-with-subversion)
-
-## Code Guidelines ##
-
-* The Liquibase project uses standard Java conventions
-* Curly braces go on the same line as the "if" statements
-* Git commit messages should include the Jira issue number, the issue summary, and a description of the how the change fixes the issue. For example "CORE-2822 YAML changelogs do not actually run included files. Finished implementation of the runIncludedChangeLog() method".
-* Prefer smaller more frequent commits over larger monolithic commits
-* Make sure your pull request target branch follows the [branching standards](branches.html).
-* Create a pull request per feature or bug. Don't combine multiple independent changes into a single pull request.
-* Include test cases for your features and bugs
diff --git a/development/index.md b/development/index.md
deleted file mode 100644
index 3175255a8..000000000
--- a/development/index.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: default
-title: Docs | Liquibase Development
----
-
-# Liquibase Development
-
-## Source Code ##
-
-The core Liquibase source code is at [http://github.com/liquibase/liquibase](http://github.com/liquibase/liquibase).
-
-All standard extensions are a part of the [http://github.com/liquibase](http://github.com/liquibase).
-
-* [How to Contribute Code](contribute.html)
-* [Branch Structure](branches.html)
-* [Code Organization](code_org.html)
-* [Building Liquibase](building.html)
-* [Javadoc](../javadoc/index.html)
-
-## Extensions vs. Core
-
-Liquibase is designed to support adding, enhancing, and overriding standard functionality through our extension framework.
-Often times, the best way to add new functionality is to create a new extension or add to an existing one rather than modifying the base library.
-
-For more information on how to write extensions, see [the extension portal](../extensions/index.html).
-
-## Issue Tracking ##
-
-**Liquibase Core**
-
-Bugs and features for the core Liquibase project are managed at [http://liquibase.jira.com/browse/CORE](http://liquibase.jira.com/browse/CORE).
-
-For more information, see [Liquibase Jira Workflow](jira.html)
-
-**Extensions**
-
-Issue tracking for extensions are handled as they see fit.
-
-For more information, see the individual extension pages on the [the extension portal](../extensions/index.html).
\ No newline at end of file
diff --git a/development/jira.md b/development/jira.md
deleted file mode 100644
index 34188e155..000000000
--- a/development/jira.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-layout: default
-title: Docs | Using Jira
----
-
-# Using Jira
-
-The core Liquibase project uses [liquibase.jira.com](http://liquibase.jira.com/browse/CORE) as its bug and feature tracker.
-
-If you have a bug or feature that you are working on or would like to have worked on, it should have an issue logged.
-
-## Jira Fields
-
-We limited down the available fields in Jira to a small but generally required set. We use them as follows:
-
-**Title/Summary** is the one line description of the feature or bug.
-
-Choose a title that is descriptive and to the point, keeping in mind that it will appear in the Jira release notes and be used by others to know what is in a release.
-
-**Issue Type** contains just three options:
-1. "Bug" for things that cause errors or do not work as expected
-1. "Feature" for brand new features
-1. "Improvement" for new functionality on existing features
-
-**Priority** contains four options:
-1. "Blocker" for bugs and missing features that are stopping you from using Liquibase
-1. "Major" for bugs and missing features that interfere with your ability to use Liquibase, but you are able to work around the problem
-1. "Nice to Have" for bugs and missing features that would be nice to have fixed or changed, but do not interfere with your usage
-1. "Trivial" for bugs and missing features that are inconsequential.
-
-**Affects Version** should contain the version in which you saw the bug the most recent version if it is a feature request.
-
-**Fix Version** should be set to the version(s) in which the change is going to be made.
-Normally this will be the next upcoming version, but if the change needs to be backported to previous release families specify both the current next version and all backported versions.
-
-For example, if 3.1.3 is the version under development, but a bug needs to be fixed in the upcoming 3.0.4 version as well, set the Fix Version to "3.1.3, 3.0.4".
-
-This should not be set until it has been determined that the issue will be fixed in a given release, either because you or someone else is actually going to fix it in that time frame.
-
-**Environment** should describe your setup for a bug or the setup improved with a feature request. Include things like database type and version, operating system, and anything else that seems relevant to diagnosing and/or reproducing the issue.
-
-**Description** should include enough information that someone else could reproduce your bug or understand the feature you want added. At a minimum, include these three things:
-1. **What I did**
- - steps you took, files used, command executed, relevant environment information
-1. **What actually happened**
- - Describe what happened, any error messages, output files, etc.
-1. **What I expected to happen**
- - This is much better than just saying "It doesn't work".
-
-## Audiences ##
-
-There are many different usages and audiences of issues entered in Jira. Remember to keep these people in mind when creating and working with Jira issues:
-
-1. **People looking through the Jira backlog looking for something to fix** There are often lots of issues to chose from and if your issue is vague or incomplete
- there is a good chance it will be skipped over.
-1. **The person fixing the bug** Make sure you are putting yourself in their shoes and thinking through what they will need. If you have done some troubleshooting or
- debugging and have any information that will make their job easier, make sure to include it.
-1. **Others that are seeing a similar issue or want a similar feature** Describe your bug or feature well enough that somebody else running into it will find your
- issue rather than creating a duplicate or variation. Not only do duplicates lead to confusion for everyone, but we lose out on the chance to collaborate on a solution.
-1. **Readers of the release notes** For each release, a link to the generated Jira release notes is made available. Make sure your title makes obvious what was changed.
-
-## Jira Workflow ##
-
-Liquibase uses "Open", "In Progress" and "Awaiting Merge" and "Closed" issues. We don't differentiate between Open vs. Reopened or Closed vs. Resolved.
-
-All new issues will be created as "Open". When anyone begins working on an issue, they should assign it themselves and change the status to "In Progress". If it turns
-out that they will not actually resolve the issue, they will unassign it and set the status back to "Open".
-
-When the fix or feature is "done" and ready to bring into the main codebase, the issue moves to "Awaiting Merge". At that point, the developer should create a GitHub pull
-request and reference the pull request in the Jira comments.
-
-If the pull request is accepted, the issue will be changed to "closed". If the pull request is rejected, discussion will normally happen within the pull request interface
-until it is either accepted or given up on at which case the issue status will go back to "Open".
-
-See the [how to contribute](contribute.html) documentation for more information on pull requests.
-
-
-
diff --git a/documentation/ant/changelogsync_ant_task.md b/documentation/ant/changelogsync_ant_task.md
deleted file mode 100644
index 477c35c7d..000000000
--- a/documentation/ant/changelogsync_ant_task.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-layout: default
-title: Docs | Changelogsync ant task
-subnav: subnav_documentation.md
----
-
-# changeLogSync Ant Task
-
-Marks all change sets as ran against the database. Useful when you have manually updated your database.
-
-## Parameters
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
changeLogFile
-
The change log file to run
-
Yes
-
-
-
contexts
-
A comma separated list of contexts to execute. If not specified, all contexts are run.
-
No
-
-
-
outputFile
-
If specified, Liquibase will save the update SQL statements to the specified file rather than executing them in the database.
-
No
-
-
-
outputEncoding
-
The character encoding to use when writing SQL statements to output file.
-
No; defaults to system encoding.
-
-
-
promptOnNonLocalDatabase
-
If set to true a dialog box with warn you if you attempt to run the Liquibase against a database that is not on localhost
-
-
No; default is false.
-
-
-
classpathref
-
A reference to the classpath used to run the task with.
-
No
-
-
-
databaseref
-
A reference to the database that Liquibase will connect to.
-
Yes, unless a nested <database> element is present.
-
-
-
driver
-
Deprecated: Name of the database driver to connect with.
-
No
-
-
-
url
-
Deprecated: Use <database>'s url attribute instead. The database URL
-
No
-
-
-
username
-
Deprecated:The database username to connect with
-
No
-
-
-
password
-
Deprecated:The password to use when connecting to the database
-
No
-
-
-
defaultSchemaName
-
Deprecated:Schema to use by default for managed database objects and Liquibase control tables
-
No
-
-
-
currentDateTimeFunction
-
Deprecated: Overrides current date time function used in SQL. Useful for unsupported databases
-
No
-
-
-
databaseChangeLogTableName
-
Deprecated: Overrides the name of the databasechangelog table to use
-
No
-
-
-
databaseChangeLogLockTableName
-
Deprecated: Overrides the name of the databasechangeloglock table to use
-
No
-
-
-
logLevel
-
Deprecated: Specifies one of the following logging levels: debug, info, warning, severe, off. The default level is info.
-
No
-
-
-
-## Parameters Specified as Nested Elements
-
-### classpath
-
-The classpath used to run the task with. Optional.
-
-### database
-
-Required unless a `databaseref` attribute is given. See [database data type](./index.html).
-
-### changelogparameters
-
-Optional. See [change log parameters](./index.html)
-
-## Examples
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-A basic implementation of the change log sync task. Syncs the change log file to the database.
-
-{% highlight xml %}
-
-
-{% endhighlight %}
-
-Syncs the referenced database with the change sets found in the given change log file.
diff --git a/documentation/ant/dbdoc_ant_task.md b/documentation/ant/dbdoc_ant_task.md
deleted file mode 100644
index 796d061b5..000000000
--- a/documentation/ant/dbdoc_ant_task.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-layout: default
-title: Docs | Dbdoc ant task
-subnav: subnav_documentation.md
----
-
-# dbDoc Ant Task
-
-Generates [dbdoc](../dbdoc.html) database documentation for a given database.
-
-## Parameters
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
changeLogFile
-
The change log file to run
-
Yes
-
-
-
contexts
-
A comma separated list of contexts to execute. If not specified, all contexts are run.
-
No
-
-
-
outputDirectory
-
The directory where the database documentation will be generated.
-
Yes
-
-
-
classpathref
-
A reference to the classpath used to run the task with.
-
No
-
-
-
databaseref
-
A reference to the database that Liquibase will connect to.
-
Yes, unless a nested <database> element is present.
-
-
-
promptOnNonLocalDatabase
-
If set to true a dialog box with warn you if you attempt to run the Liquibase against a database that is not on localhost.
-
No; default is false.
-
-
-
driver
-
Deprecated: Name of the database driver to connect with.
-
No
-
-
-
url
-
Deprecated: Use <database>'s url attribute instead. The database URL
-
No
-
-
-
username
-
Deprecated:The database username to connect with
-
No
-
-
-
password
-
Deprecated:The password to use when connecting to the database
-
No
-
-
-
defaultSchemaName
-
Deprecated:Schema to use by default for managed database objects and Liquibase control tables
-
No
-
-
-
currentDateTimeFunction
-
Deprecated: Overrides current date time function used in SQL. Useful for unsupported databases
-
No
-
-
-
databaseChangeLogTableName
-
Deprecated: Overrides the name of the databasechangelog table to use
-
No
-
-
-
databaseChangeLogLockTableName
-
Deprecated: Overrides the name of the databasechangeloglock table to use
-
No
-
-
-
logLevel
-
Deprecated: Specifies one of the following logging levels: debug, info, warning, severe, off. The default level is info.
-
No
-
-
-
-## Parameters Specified as Nested Elements
-
-### classpath
-
-The classpath used to run the task with. Optional.
-
-### database
-
-Required unless a `databaseref` attribute is given. See [database data type](./index.html).
-
-### changelogparameters
-
-Optional. See [change log parameters](./index.html)
-
-## Examples
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-A basic example of generating database documentation for a given change log file.
-
-{% highlight xml %}
-
-{% endhighlight %}
-
-Generates database documentation for the referenced database.
diff --git a/documentation/ant/diffdatabase_ant_task.md b/documentation/ant/diffdatabase_ant_task.md
deleted file mode 100644
index c5cc3000b..000000000
--- a/documentation/ant/diffdatabase_ant_task.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-layout: default
-title: Docs | Diffdatabase ant task
-subnav: subnav_documentation.md
----
-
-# diffDatabase Ant Task
-
-Outputs a [diff](../diff.html) report of the difference between two databases.
-
-## Parameters
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
outputFile
-
Location of file to save report to.
-
Yes
-
-
-
outputEncoding
-
The character encoding to use when writing to output file.
-
No; defaults to system encoding.
-
-
-
classpathref
-
A reference to the classpath used to run the task with.
-
No
-
-
-
databaseref
-
A reference to the database that Liquibase will connect to.
-
Yes, unless a nested <database> element is present.
-
-
-
referencedatabaseref
-
A reference to the reference database that Liquibase will connect to.
-
Yes, unless a nested <referencedatabase> element is present.
-
-
-
difftypes
-
A comma separated list of diff types to use.
-
No
-
-
-
promptOnNonLocalDatabase
-
If set to true a dialog box with warn you if you attempt to run the Liquibase against a database that is not on localhost.
-
No; default is false.
-
-
-
driver
-
Deprecated: Name of the database driver to connect with.
-
No
-
-
-
url
-
Deprecated: Use <database>'s url attribute instead. The database URL
-
No
-
-
-
username
-
Deprecated:The database username to connect with
-
No
-
-
-
password
-
Deprecated:The password to use when connecting to the database
-
No
-
-
-
defaultSchemaName
-
Deprecated:Schema to use by default for managed database objects and Liquibase control tables
-
No
-
-
-
currentDateTimeFunction
-
Deprecated: Overrides current date time function used in SQL. Useful for unsupported databases
-
No
-
-
-
databaseChangeLogTableName
-
Deprecated: Overrides the name of the databasechangelog table to use
-
No
-
-
-
databaseChangeLogLockTableName
-
Deprecated: Overrides the name of the databasechangeloglock table to use
-
No
-
-
-
referenceDriver
-
Deprecated: The name of the database driver to connect with.
-
No
-
-
-
referenceUrl
-
Deprecated: The base database URL.
-
No
-
-
-
referenceUsername
-
Deprecated: The base database username to connect with.
-
No
-
-
-
referencePassword
-
Deprecated: The base database password.
-
No
-
-
-
logLevel
-
Deprecated: Specifies one of the following logging levels: debug, info, warning, severe, off. The default level is info.
-
No
-
-
-
-## Parameters Specified as Nested Elements
-
-### classpath
-
-The classpath used to run the task with. Optional.
-
-### database
-
-Required unless a `databaseref` attribute is given. See [database data type](./index.html).
-
-### referencedatabase
-
-Required unless a `referencedatabaseref` attribute is given. See [database data type](./index.html).
-
-### changelogparameters
-
-Optional. See [change log parameters](./index.html)
-
-## Examples
-
-{% highlight xml %}
-
-
-
-
-{% endhighlight %}
-
-A basic implementation fo the diffDatabase task.
diff --git a/documentation/ant/diffdatabasetochangelog_ant_task.md b/documentation/ant/diffdatabasetochangelog_ant_task.md
deleted file mode 100644
index 964ed4a60..000000000
--- a/documentation/ant/diffdatabasetochangelog_ant_task.md
+++ /dev/null
@@ -1,176 +0,0 @@
----
-layout: default
-title: Docs | Diffdatabasetochangelog ant task
-subnav: subnav_documentation.md
----
-
-# diffDatabase Ant Task
-
-Outputs a [diff](../diff.html) of the difference between two databases as a change log to bring them into sync.
-
-## Parameters
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
classpathref
-
A reference to the classpath used to run the task with.
-
No
-
-
-
databaseref
-
A reference to the database that Liquibase will connect to.
-
Yes, unless a nested <database> element is present.
-
-
-
referencedatabaseref
-
A reference to the reference database that Liquibase will connect to.
-
Yes, unless a nested <referencedatabase> element is present.
-
-
-
difftypes
-
A comma separated list of diff types to use.
-
No
-
-
-
promptOnNonLocalDatabase
-
If set to true a dialog box with warn you if you attempt to run the Liquibase against a database that is not on localhost.
-
No; default is false.
-
-
-
driver
-
Deprecated: Name of the database driver to connect with.
-
No
-
-
-
url
-
Deprecated: Use <database>'s url attribute instead. The database URL
-
No
-
-
-
username
-
Deprecated:The database username to connect with
-
No
-
-
-
password
-
Deprecated:The password to use when connecting to the database
-
No
-
-
-
defaultSchemaName
-
Deprecated:Schema to use by default for managed database objects and Liquibase control tables
-
No
-
-
-
currentDateTimeFunction
-
Deprecated: Overrides current date time function used in SQL. Useful for unsupported databases
-
No
-
-
-
databaseChangeLogTableName
-
Deprecated: Overrides the name of the databasechangelog table to use
-
No
-
-
-
databaseChangeLogLockTableName
-
Deprecated: Overrides the name of the databasechangeloglock table to use
-
No
-
-
-
referenceDriver
-
Deprecated: The name of the database driver to connect with.
-
No
-
-
-
referenceUrl
-
Deprecated: The base database URL.
-
No
-
-
-
referenceUsername
-
Deprecated: The base database username to connect with.
-
No
-
-
-
referencePassword
-
Deprecated: The base database password.
-
No
-
-
-
logLevel
-
Deprecated: Specifies one of the following logging levels: debug, info, warning, severe, off. The default level is info.
-
No
-
-
-
-## Parameters Specified as Nested Elements
-
-### xml, yaml, json, or txt
-
-This task is capable of generating change log files in multiple formats. At least one of these elements is required.
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
outputfile
-
The location to write the changlog file to.
-
Yes
-
-
-
encoding
-
The file encoding to use for the output file.
-
No. Defaults to system encoding
-
-
-
-{% highlight xml %}
-
-{% endhighlight %}
-
-### classpath
-
-The classpath used to run the task with. Optional.
-
-### database
-
-Required unless a `databaseref` attribute is given. See [database data type](./index.html).
-
-### referencedatabase
-
-Required unless a `referencedatabaseref` attribute is given. See [database data type](./index.html).
-
-### changelogparameters
-
-Optional. See [change log parameters](./index.html)
-
-## Examples
-
-{% highlight xml %}
-
-
-
-
-
-{% endhighlight %}
-
-Generate a change log based on the difference between the two databases. Output the changelog to an XML file.
-
-{% highlight xml %}
-
-
-
-
-
-
-{% endhighlight %}
-
-Generate change logs in both XML and YAML format.
diff --git a/documentation/ant/dropalldatabaseobjects_ant_task.md b/documentation/ant/dropalldatabaseobjects_ant_task.md
deleted file mode 100644
index 5fd9037a6..000000000
--- a/documentation/ant/dropalldatabaseobjects_ant_task.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-layout: default
-title: Docs | Dropalldatabaseobjects ant task
-subnav: subnav_documentation.md
----
-
-# dropAllDatabaseObjects Ant Task
-
-Drops all database objects owned by the user. Note that functions, procedures and packages are not dropped (limitation in 1.8.1).
-
-## Parameters
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
promptOnNonLocalDatabase
-
If set to true a dialog box with warn you if you attempt to run the Liquibase against a database that is not on localhost
-
-
No; default is false.
-
-
-
classpathref
-
A reference to the classpath used to run the task with.
-
No
-
-
-
databaseref
-
A reference to the database that Liquibase will connect to.
-
Yes, unless a nested <database> element is present.
-
-
-
driver
-
Deprecated: Name of the database driver to connect with.
-
No
-
-
-
url
-
Deprecated: Use <database>'s url attribute instead. The database URL
-
No
-
-
-
username
-
Deprecated:The database username to connect with
-
No
-
-
-
password
-
Deprecated:The password to use when connecting to the database
-
No
-
-
-
defaultSchemaName
-
Deprecated:Schema to use by default for managed database objects and Liquibase control tables
-
No
-
-
-
currentDateTimeFunction
-
Deprecated: Overrides current date time function used in SQL. Useful for unsupported databases
-
No
-
-
-
databaseChangeLogTableName
-
Deprecated: Overrides the name of the databasechangelog table to use
-
No
-
-
-
databaseChangeLogLockTableName
-
Deprecated: Overrides the name of the databasechangeloglock table to use
-
No
-
-
-
logLevel
-
Deprecated: Specifies one of the following logging levels: debug, info, warning, severe, off. The default level is info.
-
No
-
-
-
-### classpath
-
-The classpath used to run the task with. Optional.
-
-### Database
-
-Required unless a `databaseref` attribute is given. See [database data type](./index.html).
-
-### ChangeLogParameters
-
-Optional. See [change log parameters](./index.html)
-
-## Examples
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
diff --git a/documentation/ant/generatechangelog_ant_task.md b/documentation/ant/generatechangelog_ant_task.md
deleted file mode 100644
index f52a2bd35..000000000
--- a/documentation/ant/generatechangelog_ant_task.md
+++ /dev/null
@@ -1,147 +0,0 @@
----
-layout: default
-title: Docs | Generatechangelog ant task
-subnav: subnav_documentation.md
----
-
-# generateChangeLog Ant Task
-
-[Generates changelog](../generating_changelogs.html) to re-create an existing database.
-
-## Parameters
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
classpathref
-
A reference to the classpath used to run the task with.
-
No
-
-
-
databaseref
-
A reference to the database that Liquibase will connect to.
-
Yes, unless a nested <database> element is present.
-
-
-
promptOnNonLocalDatabase
-
If set to true a dialog box with warn you if you attempt to run the Liquibase against a database that is not on localhost
-
-
No; default is false.
-
-
-
outputFile
-
Deprecated: Where to save the generated change log file.
-
No
-
-
-
driver
-
Deprecated: The name of the database driver to connect with.
-
No
-
-
-
url
-
Deprecated: The database URL.
-
No
-
-
-
username
-
Deprecated: The database username to connect with.
-
No
-
-
-
password
-
Deprecated: The password to use when connecting to the database.
-
No
-
-
-
defaultSchemaName
-
Deprecated: Schema read objects from.
-
No
-
-
-
currentDateTimeFunction
-
Deprecated: Overrides current date time function used in SQL. Useful for unsupported databases
-
No
-
-
-
databaseChangeLogTableName
-
Deprecated: Overrides the name of the databasechangelog table to use Since Liquibase 1.9
-
No
-
-
-
databaseChangeLogLockTableName
-
Deprecated: Overrides the name of the databasechangeloglock table to use Since Liquibase 1.9
-
No
-
-
-
logLevel
-
Deprecated: Specifies one of the following logging levels: debug, info, warning, severe, off. The default level is info.
-
-
No
-
-
-
-## Parameters Specified as Nested Elements
-
-### xml, yaml, json, or txt
-
-This task is capable of generating change log files in multiple formats. At least one of these elements is required.
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
outputfile
-
The location to write the changlog file to.
-
Yes
-
-
-
encoding
-
The file encoding to use for the output file.
-
No. Defaults to system encoding
-
-
-
-{% highlight xml %}
-
-{% endhighlight %}
-
-### classpath
-
-The classpath used to run the task with. Optional.
-
-### Database
-
-Required unless a `databaseref` attribute is given. See [database data type](./index.html).
-
-### ChangeLogParameters
-
-Optional. See [change log parameters](./index.html)
-
-## Examples
-
-{% highlight xml %}
-
-
-
-
-{% endhighlight %}
-
-Generates a changelog file for the database in XML format.
-
-{% highlight xml %}
-
-
-
-
-
-{% endhighlight %}
-
-Generates the change log in both XML and YAML format.
diff --git a/documentation/ant/index.md b/documentation/ant/index.md
deleted file mode 100644
index 40e34cabc..000000000
--- a/documentation/ant/index.md
+++ /dev/null
@@ -1,214 +0,0 @@
----
-layout: default
-title: Docs | Ant
-subnav: subnav_documentation.md
----
-
-# Liquibase Ant Tasks #
-
-Liquibase has a set of Ant tasks that provides
-
-## Installation
-
-The Ant tasks require Ant 1.7.1 or higher. To include the tasks in your build, make sure Liquibase is on your Ant classpath and load it via the `` task:
-
-{% highlight xml %}
-
-
-
-
-
-{% endhighlight %}
-
-You can also place the Liquibase jar in your `ANT_HOME/lib` folder.
-
-## Concepts and Types
-
-### Database
-
-All of the Liquibase Ant tasks are designed around the `` type. This element configures the database connection and corresponding settings that Liquibase will use when accessing and updating the database. It is a required in all Liquibase Ant tasks.
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
id
-
Unique identifier for this type instance, can be used to reference this type in tasks.
-
No
-
-
-
driver
-
The fully qualified class name of the JDBC driver.
-
Yes
-
-
-
url
-
The JDBC connection URL.
-
Yes
-
-
-
user
-
The username to the JDBC connection.
-
No
-
-
-
password
-
The password to the JDBC connection.
-
No
-
-
-
defaultSchemaName
-
The schema to use by default for managed database objects and Liquibase control tables.
-
No
-
-
-
defaultCatalogName
-
The catalog to use by default for managed database objects and Liquibase control tables.
-
No
-
-
-
outputDefaultSchema
-
Output the default schema name.
-
No; Default is true
-
-
-
outputDefaultCatalog
-
Output the default catalog name.
-
No; Default is true
-
-
-
liquibaseSchemaName
-
The schema name where the Liquibase tables will be located.
-
No
-
-
-
liquibaseCatalogName
-
The catalog name where the Liquibase tables will be located.
-
No
-
-
-
databaseClass
-
A fully qualified class name of a class that implements the Database interface. Used to add database types that are not officially supported by Liquibase.
-
No
-
-
-
databaseChangeLogTableName
-
Overrides the name of the DATABASECHANGELOG table.
-
No
-
-
-
databaseChangeLogLockTableName
-
Overrides the name of the DATABASECHANGELOGLOCK table.
-
No
-
-
-
liquibaseTablespaceName
-
The name of the tablespace where Liquibase tables are located.
-
No
-
-
-
-{% highlight xml %}
-
-{% endhighlight %}
-
-If you use more than one Liquibase task in your Ant build, you can create the ` anywhere in your build, give it an id, and reference it using the `databaseref` attribute:
-
-{% highlight xml %}
-
-
-
-
-{% endhighlight %}
-
-The `` type also supports a nested element `` which allows users to specify custom JDBC connection properties to Liquibase:
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-### Change Log Parameters
-
-Liquibase change log files can have parameters that are dynamically substituted at runtime. All Liquibase Ant tasks support these parameters by way of the `` element.
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-## Tasks
-
-The following tasks are available in Ant:
-
-* [updateDatabase](updatedatabase_ant_task.html)
-* [rollbackDatabase](rollbackdatabase_ant_task.html)
-* [rollbackFutureDatabase](rollbackfuturedatabase_ant_task.html)
-* [tagDatabase](tagdatabase_ant_task.html)
-* [generateChangeLog](generatechangelog_ant_task.html)
-* [diffDatabase](diffdatabase_ant_task.html)
-* [diffDatabaseToChangeLog](diffdatabasetochangelog_ant_task.html)
-* [dbDoc](dbdoc_ant_task.html)
-* [changeLogSync](changelogsync_ant_task.html)
-* [dropAllDatabaseObjects](dropalldatabaseobjects_ant_task.html)
-* [markNextChangeSetRan](marknextchangesetran_ant_task.html)
-
-Additional Liquibase commands are supported by the [command line](../command_line.html) that are not supported by the Ant tasks.
-
-## Migrating From Legacy Tasks
-
-Starting in Liquibase 3.3 the ant tasks were refactored, moving all of the database attributes out of the task and into its own type. The deprecated attributes will now log a warning message instructing callers of the deprecation. While backward compatibility exists, it is advised that users migrate their ant builds to use the new tasks.
-
-In order to use the new Liquibase tasks, the `` needs to be redefined to use the `antlib.xml` file:
-
-{% highlight xml %}
-
-
-
-
-
-{% endhighlight %}
-
-Here is an example of a legacy update task:
-
-{% highlight xml %}
-
-{% endhighlight %}
-
-Here is what it looks like migrated to the new task structure:
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
diff --git a/documentation/ant/marknextchangesetran_ant_task.md b/documentation/ant/marknextchangesetran_ant_task.md
deleted file mode 100644
index f94c40a88..000000000
--- a/documentation/ant/marknextchangesetran_ant_task.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-layout: default
-title: Docs | Marknextchangesetran ant task
-subnav: subnav_documentation.md
----
-
-# markNextChangeSetRan Ant Task
-
-Marks the next change as already ran. Useful for when a change was made manually and so an update is failing.
-
-## Parameters
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
changeLogFile
-
The change log file to run
-
Yes
-
-
-
contexts
-
A comma separated list of contexts to execute. If not specified, all contexts are run.
-
No
-
-
-
outputFile
-
If specified, Liquibase will save the update SQL statements to the specified file rather than executing them in the database.
-
No
-
-
-
outputEncoding
-
The character encoding to use when writing SQL statements to output file.
-
No; defaults to system encoding.
-
-
-
promptOnNonLocalDatabase
-
If set to true a dialog box with warn you if you attempt to run the Liquibase against a database that is not on localhost
-
-
No; default is false.
-
-
-
classpathref
-
A reference to the classpath used to run the task with.
-
No
-
-
-
databaseref
-
A reference to the database that Liquibase will connect to.
-
Yes, unless a nested <database> element is present.
-
-
-
driver
-
Deprecated: Name of the database driver to connect with.
-
No
-
-
-
url
-
Deprecated: Use <database>'s url attribute instead. The database URL
-
No
-
-
-
username
-
Deprecated:The database username to connect with
-
No
-
-
-
password
-
Deprecated:The password to use when connecting to the database
-
No
-
-
-
defaultSchemaName
-
Deprecated:Schema to use by default for managed database objects and Liquibase control tables
-
No
-
-
-
currentDateTimeFunction
-
Deprecated: Overrides current date time function used in SQL. Useful for unsupported databases
-
No
-
-
-
databaseChangeLogTableName
-
Deprecated: Overrides the name of the databasechangelog table to use
-
No
-
-
-
databaseChangeLogLockTableName
-
Deprecated: Overrides the name of the databasechangeloglock table to use
-
No
-
-
-
logLevel
-
Deprecated: Specifies one of the following logging levels: debug, info, warning, severe, off. The default level is info.
-
No
-
-
-
-## Parameters Specified as Nested Elements
-
-### classpath
-
-The classpath used to run the task with. Optional.
-
-### database
-
-Required unless a `databaseref` attribute is given. See [database data type](./index.html).
-
-### changelogparameters
-
-Optional. See [change log parameters](./index.html)
-
-## Examples
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
\ No newline at end of file
diff --git a/documentation/ant/rollbackdatabase_ant_task.md b/documentation/ant/rollbackdatabase_ant_task.md
deleted file mode 100644
index 39993fbfb..000000000
--- a/documentation/ant/rollbackdatabase_ant_task.md
+++ /dev/null
@@ -1,152 +0,0 @@
----
-layout: default
-title: Docs | Rollbackdatabase ant task
-subnav: subnav_documentation.md
----
-
-# rollbackDatabase Ant Task
-
-Rolls back database changes. See [rollback](../rollback.html) page for more information.
-
-## Parameters
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
changeLogFile
-
The change log file to rollback.
-
Yes
-
-
-
contexts
-
A comma separated list of contexts to execute. If not specified, all contexts are run.
-
No
-
-
-
outputFile
-
If specified, Liquibase will save the rollback SQL statements to the specified file rather than executing them in the database.
-
No
-
-
-
outputEncoding
-
The character encoding to use when writing SQL statements to output file.
-
No; defaults to system encoding.
-
-
-
promptOnNonLocalDatabase
-
If set to true a dialog box with warn you if you attempt to run the Liquibase against a database that is not on localhost
-
No; default is false.
-
-
-
classpathref
-
A reference to the classpath used to run the task with.
-
No
-
-
-
databaseref
-
A reference to the database that Liquibase will connect to.
-
Yes, unless a nested <database> element is present.
-
-
-
rollbackTag
-
Tag to roll back to.
-
Exactly one of these attributes must be provided.
-
-
-
rollbackDate
-
Date to roll back to.
-
-
-
rollbackCount
-
Number of changeSets to roll back.
-
-
-
driver
-
Deprecated: Name of the database driver to connect with.
-
No
-
-
-
url
-
Deprecated: Use <database>'s url attribute instead. The database URL
-
No
-
-
-
username
-
Deprecated:The database username to connect with
-
No
-
-
-
password
-
Deprecated:The password to use when connecting to the database
-
No
-
-
-
defaultSchemaName
-
Deprecated:Schema to use by default for managed database objects and Liquibase control tables
-
No
-
-
-
currentDateTimeFunction
-
Deprecated: Overrides current date time function used in SQL. Useful for unsupported databases
-
No
-
-
-
databaseChangeLogTableName
-
Deprecated: Overrides the name of the databasechangelog table to use
-
No
-
-
-
databaseChangeLogLockTableName
-
Deprecated: Overrides the name of the databasechangeloglock table to use
-
No
-
-
-
logLevel
-
Deprecated: Specifies one of the following logging levels: debug, info, warning, severe, off. The default level is info.
-
No
-
-
-
-## Parameters Specified as Nested Elements
-
-### classpath
-
-The classpath used to run the task with. Optional.
-
-### database
-
-Required unless a `databaseref` attribute is given. See [database data type](./index.html).
-
-### changelogparameters
-
-Optional. See [change log parameters](./index.html)
-
-## Examples ##
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-Rollback the last 2 change sets in the given change log file.
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-Rollback change sets to the given tag.
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-Rollback change sets to the given date/time.
diff --git a/documentation/ant/rollbackfuturedatabase_ant_task.md b/documentation/ant/rollbackfuturedatabase_ant_task.md
deleted file mode 100644
index 20f78d23f..000000000
--- a/documentation/ant/rollbackfuturedatabase_ant_task.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-layout: default
-title: Docs | Rollbackfuturedatabase ant task
-subnav: subnav_documentation.md
----
-
-# rollbackFutureDatabase Ant Task
-
-Outputs SQL to un-run changes that have not yet been executed. See [rollback](../rollback.html) for more information.
-
-## Parameters
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
changeLogFile
-
The change log file to run
-
Yes
-
-
-
contexts
-
A comma separated list of contexts to execute. If not specified, all contexts are run.
-
No
-
-
-
outputFile
-
If specified, Liquibase will save the update SQL statements to the specified file rather than executing them in the database.
-
No
-
-
-
outputEncoding
-
The character encoding to use when writing SQL statements to output file.
-
No; defaults to system encoding.
-
-
-
promptOnNonLocalDatabase
-
If set to true a dialog box with warn you if you attempt to run the Liquibase against a database that is not on localhost.
-
No; default is false.
-
-
-
classpathref
-
A reference to the classpath used to run the task with.
-
No
-
-
-
databaseref
-
A reference to the database that Liquibase will connect to.
-
Yes, unless a nested <database> element is present.
-
-
-
driver
-
Deprecated: Name of the database driver to connect with.
-
No
-
-
-
url
-
Deprecated: Use <database>'s url attribute instead. The database URL
-
No
-
-
-
username
-
Deprecated:The database username to connect with
-
No
-
-
-
password
-
Deprecated:The password to use when connecting to the database
-
No
-
-
-
defaultSchemaName
-
Deprecated:Schema to use by default for managed database objects and Liquibase control tables
-
No
-
-
-
currentDateTimeFunction
-
Deprecated: Overrides current date time function used in SQL. Useful for unsupported databases
-
No
-
-
-
databaseChangeLogTableName
-
Deprecated: Overrides the name of the databasechangelog table to use
-
No
-
-
-
databaseChangeLogLockTableName
-
Deprecated: Overrides the name of the databasechangeloglock table to use
-
No
-
-
-
logLevel
-
Deprecated: Specifies one of the following logging levels: debug, info, warning, severe, off. The default level is info.
-
No
-
-
-
-## Parameters Specified as Nested Elements
-
-### classpath
-
-The classpath used to run the task with. Optional.
-
-### database
-
-Required unless a `databaseref` attribute is given. See [database data type](./index.html).
-
-### changelogparameters
-
-Optional. See [change log parameters](./index.html)
-
-## Examples
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-A basic example of rollback future task.
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-Write the rollback future SQL to the output file.
diff --git a/documentation/ant/tagdatabase_ant_task.md b/documentation/ant/tagdatabase_ant_task.md
deleted file mode 100644
index 108661570..000000000
--- a/documentation/ant/tagdatabase_ant_task.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-layout: default
-title: Docs | Tagdatabase ant task
-subnav: subnav_documentation.md
----
-
-# tagDatabase Ant Task
-
-"Tags" the database for possible future rollback. See [rollback](../rollback.html) for more information.
-
-## Available Parameters
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
tag
-
Tag to apply to the database.
-
Yes
-
-
-
promptOnNonLocalDatabase
-
If set to true a dialog box with warn you if you attempt to run the Liquibase against a database that is not on localhost
-
-
No; default is false.
-
-
-
classpathref
-
A reference to the classpath used to run the task with.
-
No
-
-
-
databaseref
-
A reference to the database that Liquibase will connect to.
-
Yes, unless a nested <database> element is present.
-
-
-
driver
-
Deprecated: Name of the database driver to connect with.
-
No
-
-
-
url
-
Deprecated: Use <database>'s url attribute instead. The database URL
-
No
-
-
-
username
-
Deprecated:The database username to connect with
-
No
-
-
-
password
-
Deprecated:The password to use when connecting to the database
-
No
-
-
-
defaultSchemaName
-
Deprecated:Schema to use by default for managed database objects and Liquibase control tables
-
No
-
-
-
currentDateTimeFunction
-
Deprecated: Overrides current date time function used in SQL. Useful for unsupported databases
-
No
-
-
-
databaseChangeLogTableName
-
Deprecated: Overrides the name of the databasechangelog table to use
-
No
-
-
-
databaseChangeLogLockTableName
-
Deprecated: Overrides the name of the databasechangeloglock table to use
-
No
-
-
-
logLevel
-
Deprecated: Specifies one of the following logging levels: debug, info, warning, severe, off. The default level is info.
-
No
-
-
-
-### classpath
-
-The classpath used to run the task with. Optional.
-
-### Database
-
-Required unless a `databaseref` attribute is given. See [database data type](./index.html).
-
-### ChangeLogParameters
-
-Optional. See [change log parameters](./index.html)
-
-## Examples
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
diff --git a/documentation/ant/updatedatabase_ant_task.md b/documentation/ant/updatedatabase_ant_task.md
deleted file mode 100644
index 34811ae4e..000000000
--- a/documentation/ant/updatedatabase_ant_task.md
+++ /dev/null
@@ -1,151 +0,0 @@
----
-layout: default
-title: Docs | Updatedatabase ant task
-subnav: subnav_documentation.md
----
-
-# updateDatabase Ant Task
-
-Roll the database forward applying all change sets that have not been run.
-
-# Parameters
-
-
-
-
Attribute
-
Description
-
Required
-
-
-
changeLogFile
-
The change log file to run
-
Yes
-
-
-
contexts
-
A comma separated list of contexts to execute. If not specified, all contexts are run.
-
No
-
-
-
outputFile
-
If specified, Liquibase will save the update SQL statements to the specified file rather than executing them in the database.
-
No
-
-
-
outputEncoding
-
The character encoding to use when writing SQL statements to output file.
-
No; defaults to system encoding.
-
-
-
promptOnNonLocalDatabase
-
If set to true a dialog box with warn you if you attempt to run the Liquibase against a database that is not on localhost
-
-
No; default is false.
-
-
-
dropFirst
-
If set to true, Liquibase will first drop all database objects owned by the connected user.
-
No; default is false
-
-
-
classpathref
-
A reference to the classpath used to run the task with.
-
No
-
-
-
databaseref
-
A reference to the database that Liquibase will connect to.
-
Yes, unless a nested <database> element is present.
-
-
-
driver
-
Deprecated: Name of the database driver to connect with.
-
No
-
-
-
url
-
Deprecated: Use <database>'s url attribute instead. The database URL
-
No
-
-
-
username
-
Deprecated:The database username to connect with
-
No
-
-
-
password
-
Deprecated:The password to use when connecting to the database
-
No
-
-
-
defaultSchemaName
-
Deprecated:Schema to use by default for managed database objects and Liquibase control tables
-
No
-
-
-
currentDateTimeFunction
-
Deprecated: Overrides current date time function used in SQL. Useful for unsupported databases
-
No
-
-
-
databaseChangeLogTableName
-
Deprecated: Overrides the name of the databasechangelog table to use
-
No
-
-
-
databaseChangeLogLockTableName
-
Deprecated: Overrides the name of the databasechangeloglock table to use
-
No
-
-
-
logLevel
-
Deprecated: Specifies one of the following logging levels: debug, info, warning, severe, off. The default level is info.
-
No
-
-
-
-## Parameters Specified as Nested Elements
-
-### classpath
-
-The classpath used to run the task with. Optional.
-
-### database
-
-Required unless a `databaseref` attribute is given. See [database data type](./index.html).
-
-### changelogparameters
-
-Optional. See [change log parameters](./index.html)
-
-## Examples
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-A basic implementation of the update database task. Applies updates in the change log file to the database.
-
-{% highlight xml %}
-
-
-{% endhighlight %}
-
-Updates the referenced database with the change sets found in the given change log file.
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-Updates the database with the change log file, substituting any change log parameters present with values defined in the nested elements.
diff --git a/documentation/assets/liquibaseSpringBootExample/src.zip b/documentation/assets/liquibaseSpringBootExample/src.zip
deleted file mode 100644
index 084f9bbba..000000000
Binary files a/documentation/assets/liquibaseSpringBootExample/src.zip and /dev/null differ
diff --git a/documentation/cdi.md b/documentation/cdi.md
deleted file mode 100644
index f67c184f7..000000000
--- a/documentation/cdi.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-layout: default
-title: Docs | JEE CDI Integration
----
-# JEE CDI Integration #
-
-Liquibase can be run in a [JEE CDI](http://seamframework.org/Weld) environment by implementing a number of CDI Procducers methods.
-The CDI Liquibase integration is a simple CDI extension that performs a Liquibase update when the CDI container boots.
-
-
-
-## How to Configure Liquibase ##
-
-{% highlight java %}
-/**
- * A Simple CDI Producer to configure the CDI Liquibase integration
- *
- */
-public class LiquibaseProducer {
-
- @Resource
- private DataSource myDataSource;
-
- @Produces @LiquibaseType
- public CDILiquibaseConfig createConfig() {
- CDILiquibaseConfig config = new CDILiquibaseConfig();
- config.setChangeLog("liquibase/parser/core/xml/simpleChangeLog.xml");
- return config;
- }
-
- @Produces @LiquibaseType
- public DataSource createDataSource() throws SQLException {
- return myDataSource;
- }
-
- @Produces @LiquibaseType
- public ResourceAccessor create() {
- return new ClassLoaderResourceAccessor(getClass().getClassLoader());
- }
-
-}
-{% endhighlight %}
-
-
-## CDILiquibaseConfig Available Attributes ##
-
-* changeLog
-* contexts
-* parameters
-* defaultSchema
-* dropFirst **since 2.0.2**
-
-If you don't want Liquibase to run you can configure the following system property: `liquibase.should.run=false`
diff --git a/documentation/changelog_parameters.md b/documentation/changelog_parameters.md
deleted file mode 100644
index 24c915f94..000000000
--- a/documentation/changelog_parameters.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-layout: default
-title: Docs | Changelog parameters
----
-
-# Change Log Parameters #
-
-**Since Liquibase 1.7**
-
-Liquibase allows dynamic substitution of parameters in a changelog. The parameters to replace are described using the ${parameter-name} syntax.
-
-## Configuring parameter values ##
-
-Parameter values are looked up in the following order:
-
- 1. Passed as a parameter to your Liquibase runner (see [Ant](ant/index.html), [Maven](maven/index.html), [Servlet listener](servlet_listener.html)) etc. documentation for how to pass them)
- 1. As a JVM system property
- 1. As an environment variable
- 1. [command_line](command_line.html) parameter if executed from the command line
- 1. [properties file](config_properties.html) if used or executed from the command line
- 1. In the parameters block (property element) of the [DatabaseChangeLog](/documentation/databasechangelog.html) file itself
-
-Once a parameter its value cannot be changed, only the first definition is used, other are skipped.
-
-
-
-
-### <property> ###
-
-Defines a parameter for the changelog. Given a list of contexts and/or databases, the parameter will be only used in those contexts and/or databases.
-
-#### Available Attributes ####
-
-
-
Attribute
Description
-
name
Name of the parameter. Required if file is not set
-
value
Value of the of the property. required if file is not set
-
file
Name of the file the properties shall be loaded from. It will create a property for all properties in the file.
-The content of the file has to follow the java properties file format
-
context
Contexts the property is valid in. Expected as comma separated list.
-
dbms
The type of a database which that property is to be used. When the migration step is running, it checks the database type against this
- attribute. Valid database type names are listed on the supported databases page. It is possible to list multiple databases separated by commas.
- You can also specify that a changeset is NOT applicable to a particular database type by prefixing with !. The keywords all and none are
- also available.
-
global
boolean Defines whether the property is global or limited to the actual databaseChangeLog. Given as "true" or "false".
Current data type of the column to make auto-incrementRequired for: asany, h2, hsqldb, informix, ingres, mariadb, mysql, sybase, unsupportedE.g. 'int'
-
columnName
Name of the columnE.g. 'id'
-
defaultOnNull
booleanWhen using generationType 'BY DEFAULT' then defaultOnNull = true allows the identity to be used if the identity column is referenced, but a value of NULL is specified.@ v3.6Supported by: oracle
-
generationType
Type of the generation in 'GENERATED %s AS IDENTITY'. ALWAYS | BY DEFAULT@ v3.6E.g. 'ALWAYS'
-
incrementBy
integerThe value the increment incremented by each callE.g. '1'
diff --git a/documentation/changes/add_column.md b/documentation/changes/add_column.md
deleted file mode 100644
index a5f8ba7ff..000000000
--- a/documentation/changes/add_column.md
+++ /dev/null
@@ -1,152 +0,0 @@
----
-layout: default
-title: Docs | Change 'addColumn'
----
-
-
-
-
-
-
-
-# Change: 'addColumn'
-
-Adds a new column to an existing table
-
-## Available Attributes ##
-
-
-
Name
Description
-
catalogName
Name of the catalog@ v3.0E.g. 'cat'
-
schemaName
Name of the schemaE.g. 'public'
-
tableName
Name of the table to add the column toE.g. 'person'
-
-
-## Nested Properties ##
-
-
-
Name
Description
columns / column [1..N]
Column constraint and foreign key information. Setting the "defaultValue" attribute will specify a default value for the column. Setting the "value" attribute will set all rows existing to the specified value without modifying the column default.Note:columns tag not required in XML
See the column tag documentation for more information
-
-
-## SQL Generated From Above Sample (MySQL)
-
-{% highlight sql %}
-CREATE TABLE cat.state AS SELECT DISTINCT state AS abbreviation FROM address WHERE state IS NOT NULL;
-
-ALTER TABLE public.state MODIFY abbreviation CHAR(2) NOT NULL;
-
-ALTER TABLE public.state ADD PRIMARY KEY (abbreviation);
-
-ALTER TABLE address ADD CONSTRAINT fk_address_state FOREIGN KEY (state) REFERENCES public.state (abbreviation);
-
-
-{% endhighlight %}
-
-## Database Support
-
-
-
Database
Notes
Auto Rollback
-
DB2/LUW
Supported
Yes
-
DB2/z
Supported
Yes
-
Derby
Supported
Yes
-
Firebird
Not Supported
Yes
-
H2
Supported
Yes
-
HyperSQL
Not Supported
Yes
-
INGRES
Supported
Yes
-
Informix
Supported
Yes
-
MariaDB
Supported
Yes
-
MySQL
Supported
Yes
-
Oracle
Supported
Yes
-
PostgreSQL
Supported
Yes
-
SQL Server
Supported
Yes
-
SQLite
Not Supported
Yes
-
Sybase
Supported
Yes
-
Sybase Anywhere
Supported
Yes
-
diff --git a/documentation/changes/add_not_null_constraint.md b/documentation/changes/add_not_null_constraint.md
deleted file mode 100644
index 432d8d452..000000000
--- a/documentation/changes/add_not_null_constraint.md
+++ /dev/null
@@ -1,130 +0,0 @@
----
-layout: default
-title: Docs | Change 'addNotNullConstraint'
----
-
-
-
-
-
-
-
-# Change: 'addNotNullConstraint'
-
-Adds a not-null constraint to an existing table. If a defaultNullValue attribute is passed, all null values for the column will be updated to the passed value before the constraint is applied.
-
-## Available Attributes ##
-
-
-
Name
Description
-
catalogName
Name of the catalog@ v3.0E.g. 'cat'
-
columnDataType
Current data type of the columnE.g. 'int'Required for: informix, mariadb, mssql, mysql
-
columnName
Name of the column to add the constraint toE.g. 'id'
-
constraintName
Created constraint name (if database supports names for NOT NULL constraints)E.g. 'const_name'
-
defaultNullValue
Value to set all currently null values to. If not set, change will fail if null values existE.g. 'A String'
-
schemaName
Name of the schemaE.g. 'public'
-
tableName
Adds a not-null constraint to an existing table. If a defaultNullValue attribute is passed, all null values for the column will be updated to the passed value before the constraint is applied.E.g. 'person'
-
validate
booleanThis is true if the not null constraint has 'ENABLE VALIDATE' set, or false if the not null constrain has 'ENABLE NOVALIDATE' set.
-
-
-## SQL Generated From Above Sample (MySQL)
-
-{% highlight sql %}
-UPDATE cat.person SET id = 'A String' WHERE id IS NULL;
-
-ALTER TABLE cat.person MODIFY id INT NOT NULL;
-
-
-{% endhighlight %}
-
-## Database Support
-
-
-
Database
Notes
Auto Rollback
-
DB2/LUW
Supported
Yes
-
DB2/z
Not Supported
Yes
-
Derby
Supported
Yes
-
Firebird
Not Supported
Yes
-
H2
Supported
Yes
-
HyperSQL
Supported
Yes
-
INGRES
Supported
Yes
-
Informix
Supported
Yes
-
MariaDB
Supported
Yes
-
MySQL
Supported
Yes
-
Oracle
Supported
Yes
-
PostgreSQL
Supported
Yes
-
SQL Server
Supported
Yes
-
SQLite
Not Supported
Yes
-
Sybase
Supported
Yes
-
Sybase Anywhere
Supported
Yes
-
diff --git a/documentation/changes/add_primary_key.md b/documentation/changes/add_primary_key.md
deleted file mode 100644
index 99a49c943..000000000
--- a/documentation/changes/add_primary_key.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-layout: default
-title: Docs | Change 'addPrimaryKey'
----
-
-
-
-
-
-
-
-# Change: 'addPrimaryKey'
-
-Adds a primary key out of an existing column or set of columns.
-
-## Available Attributes ##
-
-
-
Name
Description
-
catalogName
Name of the catalog@ v3.0E.g. 'cat'
-
clustered
boolean
-
columnNames
Name of the column(s) to create the primary key on. Comma separated if multipleE.g. 'id, name'
-
constraintName
Name of primary key constraintE.g. 'pk_person'
-
forIndexCatalogName
-
forIndexName
E.g. 'A String'Supported by: db2, db2z, oracle
-
forIndexSchemaName
-
schemaName
Name of the schemaE.g. 'public'
-
tableName
Name of the table to create the primary key onE.g. 'person'
-
tablespace
E.g. 'A String'
-
validate
booleanThis is true if the primary key has 'ENABLE VALIDATE' set, or false if the primary key has 'ENABLE NOVALIDATE' set.
booleanCan the sequence cycle when it hits the max value?
-
dataType
Data type of the sequenceSupported by: asany, db2z, derby, firebird, h2, informix, postgresqlE.g. 'int'
-
incrementBy
integerNew amount the sequence should increment bySupported by: asany, db2, db2z, derby, firebird, informix, mssql, oracle, postgresqlE.g. '371717'
-
maxValue
integerNew maximum value for the sequenceSupported by: asany, db2, db2z, derby, firebird, h2, informix, mssql, oracle, postgresqlE.g. '371717'
-
minValue
integerNew minimum value for the sequenceE.g. '371717'
-
ordered
booleanDoes the sequence need to be guaranteed to be genererated inm the order of request?Supported by: asany, db2z, derby, firebird, h2, informix, mssql, oracle, postgresql
Name of the catalogSupported by: asany, db2, db2z, derby, firebird, h2, hsqldb, informix, ingres, mariadb, mysql, oracle, postgresql, sqlite, sybaseE.g. 'cat'
-
comments
E.g. 'A String'
-
dbms
Logical expression of database type(s) on which the change must be applied. Valid database type names are listed on the supported databases page
-It can be a comma separated list of multiple databases.
-Or You can also specify that a change is NOT applicable to a particular database type by prefixing with !. The keywords all and none are also available.@ v3.1E.g. 'h2, oracle'
-
encoding
Name of the encoding (as specified in java.nio.Charset javadoc) used in the file defined in the `path` attributeDefault: 'utf-8'
-
[XML: text content] / functionBody
E.g. 'A String'Note: the content of the tag in XML
-
functionName
Name of the function to dropE.g. 'A String'
-
path
File containing the procedure text. Either this attribute or a nested procedure text is required.E.g. 'com/example/my-logic.sql'
-
[XML: text content] / procedureText
E.g. 'CREATE OR REPLACE PROCEDURE testHello
- IS
- BEGIN
- DBMS_OUTPUT.PUT_LINE('Hello From The Database!');
- END;'Note: the content of the tag in XML
-
relativeToChangelogFile
booleanWhether the file path is relative to the root changelog file rather than to the classpath.
Logical expression of database type(s) on which the change must be applied. Valid database type names are listed on the supported databases page
-It can be a comma separated list of multiple databases.
-Or You can also specify that a change is NOT applicable to a particular database type by prefixing with !. The keywords all and none are also available.@ v3.1E.g. 'h2, oracle'
-
encoding
Name of the encoding (as specified in java.nio.Charset javadoc) used in the file defined in the `path` attributeDefault: 'utf-8'
-
packageName
Name of the package to dropE.g. 'A String'
-
[XML: text content] / packageText
E.g. 'A String'Note: the content of the tag in XML
-
path
File containing the procedure text. Either this attribute or a nested procedure text is required.E.g. 'com/example/my-logic.sql'
-
[XML: text content] / procedureText
E.g. 'CREATE OR REPLACE PROCEDURE testHello
- IS
- BEGIN
- DBMS_OUTPUT.PUT_LINE('Hello From The Database!');
- END;'Note: the content of the tag in XML
-
relativeToChangelogFile
booleanWhether the file path is relative to the root changelog file rather than to the classpath.
Logical expression of database type(s) on which the change must be applied. Valid database type names are listed on the supported databases page
-It can be a comma separated list of multiple databases.
-Or You can also specify that a change is NOT applicable to a particular database type by prefixing with !. The keywords all and none are also available.@ v3.1E.g. 'h2, oracle'
-
encoding
Name of the encoding (as specified in java.nio.Charset javadoc) used in the file defined in the `path` attributeDefault: 'utf-8'
-
packageBodyName
Name of the package body to dropE.g. 'A String'
-
[XML: text content] / packageBodyText
E.g. 'A String'Note: the content of the tag in XML
-
path
File containing the procedure text. Either this attribute or a nested procedure text is required.E.g. 'com/example/my-logic.sql'
-
[XML: text content] / procedureText
E.g. 'CREATE OR REPLACE PROCEDURE testHello
- IS
- BEGIN
- DBMS_OUTPUT.PUT_LINE('Hello From The Database!');
- END;'Note: the content of the tag in XML
-
relativeToChangelogFile
booleanWhether the file path is relative to the root changelog file rather than to the classpath.
diff --git a/documentation/changes/create_procedure.md b/documentation/changes/create_procedure.md
deleted file mode 100644
index 12b0cdfc2..000000000
--- a/documentation/changes/create_procedure.md
+++ /dev/null
@@ -1,140 +0,0 @@
----
-layout: default
-title: Docs | Change 'createProcedure'
----
-
-
-
-
-
-
-
-# Change: 'createProcedure'
-
-Defines the definition for a stored procedure. This command is better to use for creating procedures than the raw sql command because it will not attempt to strip comments or break up lines.
-
-Often times it is best to use the CREATE OR REPLACE syntax along with setting runOnChange='true' on the enclosing changeSet tag. That way if you need to make a change to your procedure you can simply change your existing code rather than creating a new REPLACE PROCEDURE call. The advantage to this approach is that it keeps your change log smaller and allows you to more easily see what has changed in your procedure code through your source control system's diff command.
-
-## Available Attributes ##
-
-
-
Name
Description
-
catalogName
Name of the catalogE.g. 'cat'
-
dbms
Logical expression of database type(s) on which the change must be applied. Valid database type names are listed on the supported databases page
-It can be a comma separated list of multiple databases.
-Or You can also specify that a change is NOT applicable to a particular database type by prefixing with !. The keywords all and none are also available.@ v3.1E.g. 'h2, !oracle, mysql'
-
encoding
Name of the encoding (as specified in java.nio.Charset javadoc) used in the file defined in the `path` attributeDefault: 'utf-8'
-
path
File containing the procedure text. Either this attribute or a nested procedure text is required.E.g. 'com/example/my-logic.sql'
-
[XML: text content] / procedureText
The SQL creating the procedure. Either this or the path attribute needs to be defined.E.g. 'CREATE OR REPLACE PROCEDURE testHello
- IS
- BEGIN
- DBMS_OUTPUT.PUT_LINE('Hello From The Database!');
- END;'Note: the content of the tag in XML
-
procedureName
Name of the procedure. Required if replaceIfExists = trueE.g. 'new_customer'Supported by: mssql
-
relativeToChangelogFile
booleanWhether the file path is relative to the root changelog file rather than to the classpath.
-
replaceIfExists
booleanIf the stored procedure defined by procedureName already exits alter it instead of creating it.Supported by: mssql
-{% highlight xml %}
-
- CREATE OR REPLACE PROCEDURE testHello
- IS
- BEGIN
- DBMS_OUTPUT.PUT_LINE('Hello From The Database!');
- END;
-
-{% endhighlight %}
-
-
-{% highlight yaml %}
-changeSet:
- id: createProcedure-example
- author: liquibase-docs
- changes:
- - createProcedure:
- catalogName: cat
- dbms: h2, !oracle, mysql
- encoding: utf8
- path: com/example/my-logic.sql
- procedureText: |-
- CREATE OR REPLACE PROCEDURE testHello
- IS
- BEGIN
- DBMS_OUTPUT.PUT_LINE('Hello From The Database!');
- END;
- procedureName: new_customer
- relativeToChangelogFile: true
- replaceIfExists: false
- schemaName: public
-
-{% endhighlight %}
-
integerThe maximum value of the sequenceSupported by: asany, db2, db2z, derby, h2, informix, mssql, oracle, postgresqlE.g. '1000'
-
minValue
integerThe minimum value of the sequenceSupported by: asany, db2, db2z, derby, h2, informix, mssql, oracle, postgresqlE.g. '10'
-
ordered
booleanDoes the sequence need to be guaranteed to be generated in the order of request?Supported by: asany, db2, db2z, derby, firebird, h2, informix, mssql, oracle
-
schemaName
Name of the schemaE.g. 'public'
-
sequenceName
Name of the sequence to createE.g. 'seq_id'
-
startValue
integerThe first sequence number to be generated.Supported by: asany, db2, db2z, derby, h2, hsqldb, informix, mssql, oracle, postgresqlE.g. '5'
Name of the catalogSupported by: asany, db2, db2z, derby, firebird, h2, hsqldb, informix, ingres, mariadb, mysql, oracle, postgresql, sqlite, sybaseE.g. 'cat'
-
comments
E.g. 'A String'
-
dbms
Logical expression of database type(s) on which the change must be applied. Valid database type names are listed on the supported databases page
-It can be a comma separated list of multiple databases.
-Or You can also specify that a change is NOT applicable to a particular database type by prefixing with !. The keywords all and none are also available.@ v3.1E.g. 'h2, oracle'
-
disabled
boolean
-
encoding
Name of the encoding (as specified in java.nio.Charset javadoc) used in the file defined in the `path` attributeDefault: 'utf-8'
-
path
File containing the procedure text. Either this attribute or a nested procedure text is required.E.g. 'com/example/my-logic.sql'
-
[XML: text content] / procedureText
E.g. 'CREATE OR REPLACE PROCEDURE testHello
- IS
- BEGIN
- DBMS_OUTPUT.PUT_LINE('Hello From The Database!');
- END;'Note: the content of the tag in XML
-
relativeToChangelogFile
booleanWhether the file path is relative to the root changelog file rather than to the classpath.
-
replaceIfExists
boolean
-
schemaName
Name of the schemaE.g. 'public'
-
scope
E.g. 'A String'
-
tableName
Name of the tableE.g. 'person'
-
[XML: text content] / triggerBody
E.g. 'A String'Note: the content of the tag in XML
-{% highlight xml %}
-
- select id, name from person where id > 10
-
-{% endhighlight %}
-
-
-{% highlight yaml %}
-changeSet:
- id: createView-example
- author: liquibase-docs
- changes:
- - createView:
- catalogName: cat
- encoding: A String
- fullDefinition: true
- path: A String
- relativeToChangelogFile: true
- remarks: A String
- replaceIfExists: false
- schemaName: public
- selectQuery: select id, name from person where id > 10
- viewName: v_person
-
-{% endhighlight %}
-
-
-{% highlight json %}
-{
- "changeSet": {
- "id": "createView-example",
- "author": "liquibase-docs",
- "changes": [
- {
- "createView": {
- "catalogName": "cat",
- "encoding": "A String",
- "fullDefinition": true,
- "path": "A String",
- "relativeToChangelogFile": true,
- "remarks": "A String",
- "replaceIfExists": false,
- "schemaName": "public",
- "selectQuery": "select id, name from person where id > 10",
- "viewName": "v_person"
- }
- }]
-
- }
-}
-
-{% endhighlight %}
-
-
-
-
-## SQL Generated From Above Sample (MySQL)
-
-{% highlight sql %}
-CREATE VIEW cat.v_person AS select id,
- name from person where id > 10;
-
-
-{% endhighlight %}
-
-## Database Support
-
-
-
Database
Notes
Auto Rollback
-
DB2/LUW
Supported
Yes
-
DB2/z
Supported
Yes
-
Derby
Supported
Yes
-
Firebird
Supported
Yes
-
H2
Supported
Yes
-
HyperSQL
Supported
Yes
-
INGRES
Supported
Yes
-
Informix
Supported
Yes
-
MariaDB
Supported
Yes
-
MySQL
Supported
Yes
-
Oracle
Supported
Yes
-
PostgreSQL
Supported
Yes
-
SQL Server
Supported
Yes
-
SQLite
Supported
Yes
-
Sybase
Supported
Yes
-
Sybase Anywhere
Supported
Yes
-
diff --git a/documentation/changes/custom_change.md b/documentation/changes/custom_change.md
deleted file mode 100644
index b7004c124..000000000
--- a/documentation/changes/custom_change.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-layout: default
-title: Docs | Change 'customChange'
----
-
-
-
-
-
-
-
-# Change: 'customChange'
-
-Although Liquibase tries to provide a wide range of database refactorings, there are times you may want to create your own custom refactoring class.
-
-To create your own custom refactoring, simply create a class that implements the [liquibase.change.custom.CustomSqlChange](/javadoc/liquibase/change/custom/CustomSqlChange.html) or [liquibase.change.custom.CustomTaskChange](/javadoc/liquibase/change/custom/CustomTaskChange.html) interface <customChange> tag in your change set.
-
-If your change can be rolled back, implement the liquibase.change.custom.CustomSqlRollback interface as well.
-
-For a sample custom change class, see liquibase.change.custom.ExampleCustomSqlChange in the test folder
-
-## Available Attributes ##
-
-
diff --git a/documentation/changes/drop_column.md b/documentation/changes/drop_column.md
deleted file mode 100644
index 746549b9b..000000000
--- a/documentation/changes/drop_column.md
+++ /dev/null
@@ -1,130 +0,0 @@
----
-layout: default
-title: Docs | Change 'dropColumn'
----
-
-
-
-
-
-
-
-# Change: 'dropColumn'
-
-Drop existing column(s).
-
-To drop a single column, use the simple form of this element where the tableName and columnName are specified as attributes. To drop several columns, specify the tableName as an attribute, and then specify a set of nested <column> tags. If nested <column> tags are present, the columnName attribute will be ignored.
-
-## Available Attributes ##
-
-
-
Name
Description
-
catalogName
Name of the catalog@ v3.0E.g. 'cat'
-
columnName
Name of the column to drop, if dropping a single column. Ignored if nested 'column's are definedE.g. 'id'
-
schemaName
Name of the schemaE.g. 'public'
-
tableName
Name of the table containing the column(s) to dropE.g. 'person'
-
-
-## Nested Properties ##
-
-
-
Name
Description
columns / column [0..N]
Columns to be dropped if dropping multiple columns. If this is populated, the columnName attribute is ignored.Note:columns tag not required in XML
diff --git a/documentation/changes/execute_command.md b/documentation/changes/execute_command.md
deleted file mode 100644
index 45bae2619..000000000
--- a/documentation/changes/execute_command.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-layout: default
-title: Docs | Change 'executeCommand'
----
-
-
-
-
-
-
-
-# Change: 'executeCommand'
-
-Executes a system command. Because this refactoring doesn't generate SQL like most, using Liquibase commands such as migrateSQL may not work as expected. Therefore, if at all possible use refactorings that generate SQL.
-
-## Available Attributes ##
-
-
diff --git a/documentation/changes/index.md b/documentation/changes/index.md
deleted file mode 100644
index b1630f060..000000000
--- a/documentation/changes/index.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-layout: default
-title: Docs | Refactorings
----
-
-# Bundled Liquibase Changes
-
-Liquibase ships with a large number of refactoring/changes that can be applied to your database as well as the ability to write more through the
-[extension system](../../extensions/index.html).
-
-#### Note
-- Property values are string except noted
-- Boolean parameters are defaulted to false unless otherwise noted
-
-
-| **Entity**| Create / Add | Drop | Change
-|====|===|
-| Table | [createTable](create_table.html) | [dropTable](drop_table.html) | [renameTable](rename_table.html) [setTableRemarks](set_table_remarks.html)
-| Column | [addColumn](add_column.html) | [dropColumn](drop_column.html) | [renameColumn](rename_column.html) [modityDataType](modify_data_type.html) [setColumnRemarks](set_column_remarks.html) [addAutoIncrement](add_auto_increment.html)
-| Index | [createIndex](create_index.html) | [dropIndex](drop_index.html) |
-| View | [createView](create_view.html) | [dropView](drop_view.html) | [renameView](rename_view.html)
-| Procedure | [createProcedure](create_procedure.html) | [dropProcedure](drop_procedure.html) |
-| Sequence | [createSequence](create_sequence.html) | [dropSequence](drop_sequence.html) | [renameSequence](rename_sequence.html) [alterSequence](alter_sequence.html)
-
-| **Constraint**| Add | Drop
-|====|===|
-| Check | [addCheckConstraint](add_check_constraint.html) | [dropConstraint](drop_check_constraint.html)
-| Default value | [addDefaultValue](add_default_value.html) | [dropDefaultValue](drop_default_value.html)
-| Foreign key | [addForeignKeyConstraint](add_foreign_key_constraint.html) | [dropForeignKeyConstraint](drop_foreign_key_constraint.html)
-| Not null | [addNotNullConstraint](add_not_null_constraint.html) | [dropNotNullConstraint](drop_not_null_constraint.html)
-| Primary key | [addPrimaryKey](add_primary_key.html) | [dropPrimaryKey](drop_primary_key.html)
-| Unique key | [addUniqueKeyConstraint](add_unique_constraint.html) | [dropUniqueKeyConstraint](drop_unique_constraint.html)
-
-| **Data**|
-|====|===|
-| [insert](insert.html) | [update](update.html) | [delete](delete.html) | [loadData](load_data.html) | [loadUpdateData](load_update_data.html) | [mergeColumns](merge_columns.html) | [addLookupTable](add_lookup_table.html)
-
-| **Misc**|
-|====|===|
-| [sql](sql.html) | [sqlFile](sql_file.html) | [executeCommand](execute_command.html) | [tagDatabase](tag_database.html) | [stop](stop.html) | [output](output.html) | [customChange](custom_change.html)
\ No newline at end of file
diff --git a/documentation/changes/insert.md b/documentation/changes/insert.md
deleted file mode 100644
index ca49f5a61..000000000
--- a/documentation/changes/insert.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-layout: default
-title: Docs | Change 'insert'
----
-
-
-
-
-
-
-
-# Change: 'insert'
-
-Inserts data into an existing table
-
-## Available Attributes ##
-
-
-
Name
Description
-
catalogName
Name of the catalog@ v3.0E.g. 'cat'
-
dbms
Logical expression of database type(s) on which the change must be applied. Valid database type names are listed on the supported databases page
-It can be a comma separated list of multiple databases.
-Or You can also specify that a change is NOT applicable to a particular database type by prefixing with !. The keywords all and none are also available.@ v3.0E.g. '!h2, mysql'
-
schemaName
Name of the schemaE.g. 'public'
-
tableName
Name of the table to insert data intoE.g. 'person'
-
-
-## Nested Properties ##
-
-
-
Name
Description
columns / column [1..N]
Data to insert into columnsNote:columns tag not required in XML
diff --git a/documentation/changes/load_data.md b/documentation/changes/load_data.md
deleted file mode 100644
index bfb88a833..000000000
--- a/documentation/changes/load_data.md
+++ /dev/null
@@ -1,176 +0,0 @@
----
-layout: default
-title: Docs | Change 'loadData'
----
-
-
-
-
-
-
-
-# Change: 'loadData'
-
-Loads data from a CSV file into an existing table. A value of NULL in a cell will be converted to a database NULL rather than the string 'NULL'.
-Lines starting with # (hash) sign are treated as comments. You can change comment pattern by specifying 'commentLineStartsWith' property in loadData tag.To disable comments set 'commentLineStartsWith' to empty value'
-
-If the data type for a load column is set to NUMERIC, numbers are parsed in US locale (e.g. 123.45).
-Date/Time values included in the CSV file should be in ISO format http://en.wikipedia.org/wiki/ISO_8601 in order to be parsed correctly by Liquibase. Liquibase will initially set the date format to be 'yyyy-MM-dd'T'HH:mm:ss' and then it checks for two special cases which will override the data format string.
-
-If the string representing the date/time includes a '.', then the date format is changed to 'yyyy-MM-dd'T'HH:mm:ss.SSS'
-If the string representing the date/time includes a space, then the date format is changed to 'yyyy-MM-dd HH:mm:ss'
-Once the date format string is set, Liquibase will then call the SimpleDateFormat.parse() method attempting to parse the input string so that it can return a Date/Time. If problems occur, then a ParseException is thrown and the input string is treated as a String for the INSERT command to be generated.
-If UUID type is used UUID value is stored as string and NULL in cell is supported.
-
-## Available Attributes ##
-
-
-
Name
Description
-
catalogName
Name of the catalog@ v3.0E.g. 'cat'
-
commentLineStartsWith
Lines starting with this character are treated as comment and ignored.Default: '#'
-
encoding
Encoding of the CSV file (defaults to UTF-8)Default: 'utf-8'
-
file
CSV file to loadE.g. 'com/example/users.csv'
-
quotchar
The quote character for string fields containing the separator character.Default: '"'
-
relativeToChangelogFile
booleanWhether the file path is relative to the root changelog file rather than to the classpath.
-
schemaName
Name of the schemaE.g. 'public'
-
separator
Character separating the fields.Default: ','
-
tableName
Name of the table to insert data intoE.g. 'person'
-
usePreparedStatements
booleanUse prepared statements instead of insert statement strings if the DB supports it
-
-
-## Nested Properties ##
-
-
-
Name
Description
columns / column [0..N]
CSV -> table column mapping can be defined.
-
-Either the 'header' or 'index' attribute needs to be defined for columns if the header name in the CSV is different than the column needs to be inserted
-If no `column` defined at all, header names has to match the column names in the table.The column type it is taken from the DB. Otherwise for non-string columns the type definition might be requiredNote:columns tag not required in XML
diff --git a/documentation/changes/load_update_data.md b/documentation/changes/load_update_data.md
deleted file mode 100644
index 363fa2028..000000000
--- a/documentation/changes/load_update_data.md
+++ /dev/null
@@ -1,177 +0,0 @@
----
-layout: default
-title: Docs | Change 'loadUpdateData'
----
-
-
-
-
-
-
-
-# Change: 'loadUpdateData'
-
-Loads or updates data from a CSV file into an existing table. Differs from loadData by issuing a SQL batch that checks for the existence of a record. If found, the record is UPDATEd, else the record is INSERTed. Also, generates DELETE statements for a rollback.
-
-A value of NULL in a cell will be converted to a database NULL rather than the string 'NULL'
-
-## Available Attributes ##
-
-
-
Name
Description
-
catalogName
Name of the catalog@ v3.0E.g. 'cat'
-
commentLineStartsWith
Lines starting with this character are treated as comment and ignored.Default: '#'
-
encoding
Encoding of the CSV file (defaults to UTF-8)Default: 'utf-8'
-
file
CSV file to loadE.g. 'com/example/users.csv'
-
onlyUpdate
booleanIf true, records with no matching database record should be ignored@ v3.3
-
primaryKey
Comma delimited list of the columns for the primary keyE.g. 'pk_id'
-
quotchar
The quote character for string fields containing the separator character.Default: '"'
-
relativeToChangelogFile
booleanWhether the file path is relative to the root changelog file rather than to the classpath.
-
schemaName
Name of the schemaE.g. 'public'
-
separator
Character separating the fields.Default: ','
-
tableName
Name of the table to insert or update data inE.g. 'person'
-
usePreparedStatements
booleanUse prepared statements instead of insert statement strings if the DB supports it
-
-
-## Nested Properties ##
-
-
-
Name
Description
columns / column [0..N]
CSV -> table column mapping can be defined.
-
-Either the 'header' or 'index' attribute needs to be defined for columns if the header name in the CSV is different than the column needs to be inserted
-If no `column` defined at all, header names has to match the column names in the table.The column type it is taken from the DB. Otherwise for non-string columns the type definition might be requiredNote:columns tag not required in XML
diff --git a/documentation/changes/merge_columns.md b/documentation/changes/merge_columns.md
deleted file mode 100644
index 5966308a9..000000000
--- a/documentation/changes/merge_columns.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-layout: default
-title: Docs | Change 'mergeColumns'
----
-
-
-
-
-
-
-
-# Change: 'mergeColumns'
-
-Concatenates the values in two columns, joins them by with string, and stores the resulting value in a new column.
-
-## Available Attributes ##
-
-
-
Name
Description
-
catalogName
Name of the catalogE.g. 'cat'
-
column1Name
Name of the column containing the first half of the dataE.g. 'first_name'
-
column2Name
Name of the column containing the second half of the dataE.g. 'last_name'
-
finalColumnName
Name of the column to createE.g. 'full_name'
-
finalColumnType
Data type of the column to createE.g. 'varchar(255)'
-
joinString
String to place include between the values from column1 and column2 (may be empty)E.g. 'A String'
-
schemaName
Name of the schemaE.g. 'public'
-
tableName
Name of the table containing the columns to joinE.g. 'person'
diff --git a/documentation/changes/sql.md b/documentation/changes/sql.md
deleted file mode 100644
index 71f62d384..000000000
--- a/documentation/changes/sql.md
+++ /dev/null
@@ -1,134 +0,0 @@
----
-layout: default
-title: Docs | Change 'sql'
----
-
-
-
-
-
-
-
-# Change: 'sql'
-
-The 'sql' tag allows you to specify whatever sql you want. It is useful for complex changes that aren't supported through Liquibase's automated refactoring tags and to work around bugs and limitations of Liquibase. The SQL contained in the sql tag can be multi-line.
-
-The createProcedure refactoring is the best way to create stored procedures.
-
-The 'sql' tag can also support multiline statements in the same file. Statements can either be split using a ; at the end of the last line of the SQL or a 'GO' on its own on the line between the statements can be used. Multiline SQL statements are also supported and only a ; or GO statement will finish a statement, a new line is not enough. Files containing a single statement do not need to use a ; or GO.
-
-The sql change can also contain comments of either of the following formats:
-
-A multiline comment that starts with /\* and ends with \*/.
-A single line comment starting with <space>--<space> and finishing at the end of the line.
-Note: By default it will attempt to split statements on a ';' or 'go' at the end of lines. Because of this, if you have a comment or some other non-statement ending ';' or 'go', don't have it at the end of a line or you will get invalid SQL.
-
-## Available Attributes ##
-
-
-
Name
Description
-
dbms
Logical expression of database type(s) on which the change must be applied. Valid database type names are listed on the supported databases page
-It can be a comma separated list of multiple databases.
-Or You can also specify that a change is NOT applicable to a particular database type by prefixing with !. The keywords all and none are also available.@ v3.0E.g. 'h2, oracle'
-
endDelimiter
Delimiter to apply to the end of the statement. Defaults to ';', may be set to ''.E.g. '\nGO'
-
splitStatements
booleanSet to false to not have liquibase split statements on ;'s and GO's. Defaults to true if not setDefault: true
-
[XML: text content] / sql
The SQL to executeE.g. 'insert into person (name) values ('Bob')'Note: the content of the tag in XML
-
stripComments
booleanSet to true to remove any comments in the SQL before executing, otherwise false. Defaults to false if not set
-
-
-## SQL Generated From Above Sample (MySQL)
-
-{% highlight sql %}
-insert into person (name) values ('Bob')
-GO
-
-
-{% endhighlight %}
-
-## Database Support
-
-
-
Database
Notes
Auto Rollback
-
DB2/LUW
Supported
No
-
DB2/z
Supported
No
-
Derby
Supported
No
-
Firebird
Supported
No
-
H2
Supported
No
-
HyperSQL
Supported
No
-
INGRES
Supported
No
-
Informix
Supported
No
-
MariaDB
Supported
No
-
MySQL
Supported
No
-
Oracle
Supported
No
-
PostgreSQL
Supported
No
-
SQL Server
Supported
No
-
SQLite
Supported
No
-
Sybase
Supported
No
-
Sybase Anywhere
Supported
No
-
diff --git a/documentation/changes/sql_file.md b/documentation/changes/sql_file.md
deleted file mode 100644
index 5a75d40f4..000000000
--- a/documentation/changes/sql_file.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-layout: default
-title: Docs | Change 'sqlFile'
----
-
-
-
-
-
-
-
-# Change: 'sqlFile'
-
-The 'sqlFile' tag allows you to specify any sql statements and have it stored external in a file. It is useful for complex changes that are not supported through Liquibase's automated refactoring tags such as stored procedures.
-
-The sqlFile refactoring finds the file by searching in the following order:
-
-The file is searched for in the classpath. This can be manually set and by default the Liquibase startup script adds the current directory when run.
-The file is searched for using the file attribute as a file name. This allows absolute paths to be used or relative paths to the working directory to be used.
-The 'sqlFile' tag can also support multiline statements in the same file. Statements can either be split using a ; at the end of the last line of the SQL or a go on its own on the line between the statements can be used.Multiline SQL statements are also supported and only a ; or go statement will finish a statement, a new line is not enough. Files containing a single statement do not need to use a ; or go.
-
-The sql file can also contain comments of either of the following formats:
-
-A multiline comment that starts with /\* and ends with \*/.
-A single line comment starting with <space>--<space> and finishing at the end of the line
-
-## Available Attributes ##
-
-
-
Name
Description
-
dbms
Logical expression of database type(s) on which the change must be applied. Valid database type names are listed on the supported databases page
-It can be a comma separated list of multiple databases.
-Or You can also specify that a change is NOT applicable to a particular database type by prefixing with !. The keywords all and none are also available.@ v3.0E.g. 'h2, oracle'
-
encoding
Name of the encoding (as specified in java.nio.Charset javadoc) used in the file defined in the `path` attributeDefault: 'utf-8'
-
endDelimiter
Delimiter to apply to the end of the statement. Defaults to ';', may be set to ''.E.g. '\nGO'
-
path
The file path of the SQL file to loadE.g. 'my/path/file.sql'
-
relativeToChangelogFile
booleanWhether the file path is relative to the root changelog file rather than to the classpath.
-
splitStatements
booleanSet to false to not have liquibase split statements on ;'s and GO's. Defaults to true if not setDefault: true
-
stripComments
booleanSet to true to remove any comments in the SQL before executing, otherwise false. Defaults to false if not set
-
-
-## SQL Generated From Above Sample (MySQL)
-
-{% highlight sql %}
-UPDATE cat.person SET address = 'address value' WHERE name='Bob';
-
-
-{% endhighlight %}
-
-## Database Support
-
-
-
Database
Notes
Auto Rollback
-
DB2/LUW
Supported
No
-
DB2/z
Supported
No
-
Derby
Supported
No
-
Firebird
Supported
No
-
H2
Supported
No
-
HyperSQL
Supported
No
-
INGRES
Supported
No
-
Informix
Supported
No
-
MariaDB
Supported
No
-
MySQL
Supported
No
-
Oracle
Supported
No
-
PostgreSQL
Supported
No
-
SQL Server
Supported
No
-
SQLite
Supported
No
-
Sybase
Supported
No
-
Sybase Anywhere
Supported
No
-
diff --git a/documentation/changeset.md b/documentation/changeset.md
deleted file mode 100644
index db120a9df..000000000
--- a/documentation/changeset.md
+++ /dev/null
@@ -1,139 +0,0 @@
----
-layout: default
-title: Docs | Changeset tag
----
-
-# changeSet tag
-
-The changeSet tag is what you use to group database changes/refactorings together.
-
-{% highlight xml %}
-
-
-
-
- A sample change log
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-Each changeSet tag is uniquely identified by the combination of the "id" tag, the "author" tag, and the changelog file classpath name. The id tag is only used as an identifier, it does not direct the order that changes are run and does not even have to be an integer. If you do not know or do not wish to save the actual author, simply use a placeholder value such as "UNKNOWN".
-
-As Liquibase executes the databaseChangeLog, it reads the changeSets in order and, for each one, checks the "databasechangelog" table to see if the combination of id/author/filepath has been run. If it has been run, the changeSet will be skipped unless there is a true "runAlways" tag. After all the changes in the changeSet are run, Liquibase will insert a new row with the id/author/filepath along with an MD5Sum of the changeSet (see below) in the "databasechangelog".
-
-Note
-: filepath is the path how the changeLogFile parameter is defined. Even if the same file is referenced with a different path, that is considered a different file unless the logicalFilePath is defined.
-
-Liquibase attempts to execute each changeSet in a transaction that is committed at the end, or rolled back if there is an error. Some databases will auto-commit statements which interferes with this transaction setup and could lead to an unexpected database state. Therefore, it is usually best to have just one change per changeSet unless there is a group of non-auto-committing changes that you want applied as a transaction such as inserting data.
-
-## Available Attributes ##
-
-
-
id
An alpha-numeric identifier required
-
author
The creator of the change set required
-
dbms
The type of a database which that changeSet is to be used for. When the migration step is running, it checks the database type against this
- attribute. Valid database type names are listed on the supported databases page. It is possible to list multiple databases separated by commas.
- You can also specify that a changeset is NOT applicable to a particular database type by prefixing with !. The keywords all and none are
- also available.
-
runAlways
Executes the change set on every run, even if it has been run before
-
runOnChange
Executes the change the first time it is seen and each time the change set has been changed
Controls whether a changeset is executed, depending on runtime settings. Any string can be used for the context name and they are checked case-insensitively.
Controls whether a changeset is executed, depending on runtime settings. Any string can be used for the label name and they are checked case-insensitively.
-
runInTransaction
Should the changeSet be ran as a single transaction (if possible)? Defaults to true. Warning: be careful with this attribute. If set to false and an error occurs part way through running a changeSet containing multiple statements, the Liquibase databasechangelog table will be left in an invalid state. Since 1.9
-
failOnError
Should the migration fail if an error occurs while executing the changeSet? Default=true
-
objectQuotingStrategy
This controls how object names are quoted in the SQL generated or used in calls to the database. Different databases do different things to
-the names of objects, for example Oracle converts everything to uppercase (unless quoted). There are three possible values. The default value is LEGACY.
-LEGACY - Same behavior as in Liquibase 2.0
-QUOTE_ALL_OBJECTS - Every object gets quoted. e.g. person becomes "person".
-QUOTE_ONLY_RESERVED_WORDS - Quote reserved keywords and invalid column names.
-
runOrder
Since 3.5
-
created
Since 3.5
-
ignore
Ignore the changesSet from the executionSince 3.6
-
logicalFilePath
Use to override the file name and path when creating the unique identifier of change sets. Required when moving or renaming change logs.
-
-
-
-## Available Sub-Tags ##
-
-
-
comment
A description of the change set. XML comments will provide the same benefit, future releases of Liquibase may be able to make use of <comment> tag comments to generate documentation
-
preConditions
Preconditions that must pass before the change set will be executed. Useful for doing a data sanity check before doing something unrecoverable such as a dropTable Since 1.7
-
<Any Refactoring Tag(s)>
The database change(s) to run as part of this change set (so called refactorings)
-
validCheckSum
Add a checksum that is considered valid for this changeSet, regardless of what is stored in the database. Used
-primarily when you need to change a changeSet and don't want errors thrown on databases on which it has already run (not a recommended procedure). Special value "1:any" will match to any checksum and not execute the changeSet on ANY changeSince 1.7
-
rollback
SQL statements or refactoring tags that describe how to rollback the change set
-
-
-
-
-### Rollback Tag ###
-
-The rollback tag describes how to roll back a change using SQL statement(s), change tags, or a reference to a previous change set.
-
-#### Rollback Tag Examples ####
-
-Here we see that you can just have plain SQL in the content part of the `` element. The text in the element is treated as a `` change with `stripComments` set to `true`,
-`splitStatements` set to `true` and `endDelimiter` set to `;`.
-{% highlight xml %}
-
-
-
- drop table testTable
-
-
-{% endhighlight %}
-
-Here we see that you can have any type of change in the `` element.
-{% highlight xml %}
-
-
-
-
-
-
-{% endhighlight %}
-
-This example shows how a `` element can refer to another changeset. This would be interpreted as "In order to roll back this changeset (id="2"), apply the changeset with id=1"
-{% highlight xml %}
-
-
-
-
-{% endhighlight %}
-
-
-## ChangeSet Check Sums ##
-
-When Liquibase reaches a changeSet, it computes a check sum and stores it in the "databasechangelog". The value of storing the check sum is so that Liquibase can know if
-someone changed the changes in the changeSet since it was run. If the changeSet was changed since it was run, Liquibase will exit the migration with an error message like
-`Validation failed: change set check sums was: but is now: `. This is because Liquibase cannot know what was changed and the
-database may be in a state different than what the changeLog is expecting. If there was a valid reason for the changeSet to have
-been changed and you want to ignore this error, you have two options.
-
-The first option is to manually update the databasechangelog table so that the row with the corresponding id/author/filepath has a null value for the check sum. You would
-need to do this for all environments where the changeset has been deployed. The next time you run the Liquibase update command, it will update the check sum value to the new correct value.
-
-The second option is to add a `` element to the changeset. The text contents of the element should be the "old" checksum from the error message.
-
-
-Check sums are also used in conjunction with the "runOnChange" changeSet attribute. There are times you may not want to add a new changeSet because you only need to know
-about the current version, but you want this change applied whenever it is updated. A good example of when you would want this is stored procedures. If you copy the entire
-text of the stored procedure to a new changeSet each time you make a change you will not only end up with a very long changeLog, but you will lose the merging and diff-ing
-power of your source control. Instead, put the text of the stored procedure in a changeSet with a runOnChange="true" attribute. The stored procedure will be re-created
-when and only when there is a change to the text of it.
diff --git a/documentation/column.md b/documentation/column.md
deleted file mode 100644
index 50bda7efa..000000000
--- a/documentation/column.md
+++ /dev/null
@@ -1,255 +0,0 @@
----
-layout: default
-title: Docs | Column tag
----
-
-# Column tag #
-
-The "column" tag is a tag that is re-used throughout the Liquibase XML when column definitions and column information is needed. As a result, not all the attributes of column make sense in each context it is used in.
-
-## Available Attributes ##
-
-
-
-
-
Attribute
-
Description
-
-
-
-
-
name
-
Name of the column
-
-
-
type
-
Column data type
-
-
-
value
-
Value to set the column to. The value will be surrounded by quote marks and nested quote marks will be escaped. Please note that setting the "value" attribute will set all rows existing to the specified value without modifying the column default. Setting the "defaultValue" attribute will specify a default value for the column.
-
-
-
computed
-
Used if the value in "name" isn't actually a column name but actually a function. Since 3.3.0
-
-
-
valueNumeric
-
Numeric value to set the column to. The value will not be escaped and will not be nested in quote marks.
-
-
-
valueBoolean
-
Boolean value to set the column to. The actual value string inserted will be dependent on the database implementation.
-
-
-
valueDate
-
Date and/or Time value to set the column to. The value is specified in one of the following forms: "YYYY-MM-DD", "hh:mm:ss" or "YYYY-MM-DDThh:mm:ss".
-
-
-
valueComputed
-
A value that is returned from a function or procedure call. This attribute will contain the function to call.
-
-
-
valueBlobFile
-
Path to a file, whose contents will be written as a BLOB (i.e. chunk of binary data). Must be either absolute or relative to the Change Log file location (absolute paths are, e.g.: /usr/local/somefile.dat on Unix or c:\Directory\somefile.dat on Windows. Please refer to java.io.File javadoc for the details of what to consider relative/absolute path).
-
-
-
valueClobFile
-
Path to a file, whose contents will be written as a CLOB (i.e. chunk of character data). Must be either absolute or relative to the Change Log file location (absolute paths are, e.g.: /usr/local/somefile.dat on Unix or c:\Directory\somefile.dat on Windows. Please refer to java.io.File javadoc for the details of what to consider relative/absolute path).
-
-
-
encoding
-
Name of the encoding (as specified in java.nio.Charset javadoc, e.g. "UTF-8") of the CLOB file (specified in valueClobFile) contents.
Note: used only when valueClobFile attribute is specified, ignored otherwise.
-
-
-
defaultValue
-
Default value for column.
-
Note: If not set the first defaultValueXXX defined is used in the order they
- appear.
-
-
-
defaultValueNumeric
-
Default numeric value for column
-
-
-
defaultValueBoolean
-
Default boolean value for column
-
-
-
defaultValueDate
-
Default date and/or time value for column. The value is specified in one of the following forms: "YYYY-MM-DD", "hh:mm:ss" or "YYYY-MM-DDThh:mm:ss"
-
-
-
defaultValueComputed
-
A value that is returned from a function or procedure call. This attribute will contain the function to call.
-
-
-
autoIncrement
-
Is column an auto-increment column. Ignored on databases that do not support autoincrement/identity functionality.
-
-
-
startWith
-
The value auto-increment start. Ignored on databases that do not support autoincrement/identity functionality.
-
-
-
incrementBy
-
The value of each step by auto-increment. Ignored on databases that do not support autoincrement/identity functionality.
-
-
-
remarks
-
Short description of the column (column comment)
-
-
-
beforeColumn
-
If used in an 'addColumn' command, this attribute allows you to control where in the table column order the new column goes. Only one of beforeColumn, afterColumn or position are allowed. Since 3.1
-
-
-
afterColumn
-
If used in an 'addColumn' command, this attribute allows you to control where in the table column order the new column goes. Only one of beforeColumn, afterColumn or position are allowed. Since 3.1
-
-
-
position
-
If used in an 'addColumn' command, this attribute allows you to control where in the table column order the new column goes. Only one of beforeColumn, afterColumn or position are allowed. Expects a one based index Since 3.1
-
-
-
descending
-
If used in a 'createIndex' command, this boolean attribute allows you to specify that a column should be used in descending order in the index. Defaults to false (i.e. ascending order) Since 3.4
-
-
-
-
-
-To help make scripts database-independent, the following "generic" data types will be converted to the correct database implementation:
-
-* BOOLEAN
-* CURRENCY
-* UUID
-* CLOB
-* BLOB
-* DATE
-* DATETIME
-* TIME
-* BIGINT
-
-Also, specifying a java.sql.Types.* type will be converted to the correct type as well. If needed, precision can be included. Here are some examples:
-
-* java.sql.Types.TIMESTAMP
-* java.sql.Types.VARCHAR(255)
-
-## Available Sub-Tags ##
-
-
-
-
-
Tag
-
Description
-
-
-
-
-
constraints
-
Constraint definitions
-
-
-
-
-# Constraints tag #
-
-The "constraints" tag contains information about constraints on the column.
-
-## Available Attributes ##
-
-
-
-
-
Attribute
-
Description
-
-
-
-
-
nullable
-
Is column nullable?
-
-
-
notNullConstraintName
-
The not null constraint name
-
-
-
primaryKey
-
Is column a primary key?
-
-
-
primaryKeyName
-
Primary key name Since 1.6
-
-
-
primaryKeyTablespace
-
The tablespace to use for the defined primary key
-
-
-
unique
-
Should a unique clause be applied?
-
-
-
uniqueConstraintName
-
The unique constraint name
-
-
-
references
-
Foreign key definition
-
-
-
referencedTableCatalogName
-
Name of the catalog
-
-
-
referencedTableSchemaName
-
Name of the schema
-
-
-
referencedTableName
-
Name of the table
-
-
-
referencedColumnNames
-
Name of the column
-
-
-
foreignKeyName
-
Foreign key name
-
-
-
deleteCascade
-
Set delete cascade
-
-
-
deferrable
-
Are constraints deferrable?
-
-
-
initiallyDeferred
-
Are constraints initially deferred?
-
-
-
validateNullable
-
Should validate the defined not null constraint?
-
-
-
validateUnique
-
Should validate the defined unique constraint?
-
-
-
validatePrimaryKey
-
Should validate the defined primary key constraint?
-
-
-
validateForeignKey
-
Should validate the defined foreign key constraint?
-
-
-
checkConstraint
-
Should validate the defined check constraint?
-
-
-
diff --git a/documentation/command_line.md b/documentation/command_line.md
deleted file mode 100644
index 3dd4647a6..000000000
--- a/documentation/command_line.md
+++ /dev/null
@@ -1,279 +0,0 @@
----
-layout: default
-title: Docs | Command line
----
-
-# Liquibase Command Line #
-
-Liquibase can be run from the command line by running:
-
-{% highlight bat %}
-liquibase [global options] [command] [command parameters]
-{% endhighlight %}
-
-The command line migrator works well when you want to do migrations on demand, but don't have Ant or Maven available such as on servers.
-The command line migrator also gives you more control over the process than the [servlet listener](servlet_listener.html), [Ant](ant/index.html),
-or [Maven](maven/index.html) do, allowing you to run maintenance commands like outputting SQL and listing/releasing database changelog locks.
-
-Any values found after the command on the command line invocation will be considered a command parameter. The command line processor will
-validate whether the command line parameters are allowed for the current command. If the current command does not allow command line
-parameters or the parameter appears to be an incorrect format, then an error message of 'unexpected command parameter' will be logged
-and the execution will terminate.
-
-The command line migrator also allows you to
-
-* [perform rollback operations and generate rollback scripts](rollback.html)
-* [generate "diffs"](diff.html)
-* [generate creation scripts from existing databases](generating_changelogs.html)
-* [generate database change documentation](dbdoc.html)
-
-If you run the command line migrator without any arguments, you will get a help message listing these available commands:
-
-## Database Update Commands ##
-
-
Generate a changelog from a database when adding Liquibase to a new project.
-Conceptually, does a diff of the current database to an empty database, creating a changelog that has all the changes needed to update an empty database.
Generates Javadoc-like documentation based on current database and change log.
-
-
-
-## Maintenance Commands ##
-
-
-
Command
Description
-
changelogSync
Mark all changes as executed in the database.
-
changelogSyncSQL
Writes SQL to mark all changes as executed in the database to STDOUT.
-
clearCheckSums
Removes current checksums from database. On next update changesets that
- have already been deployed will have their checksums recomputed, and changesets that have not been deployed
- will be deployed.
-
dropAll
Drops all database objects owned by the user. DANGEROUS!
-
listLocks
Lists who currently has locks on the database changelog.
-
markNextChangeSetRan
Mark the next change set as executed in the database.
-
releaseLocks
Releases all locks on the database changelog.
-
status
Outputs count (list if --verbose) of unrun change sets.
Gathers the current database schema and displays that information to STDOUT. With options, can save
-the schema in JSON format, and that JSON snapshot can serve as a comparison database.
-
tag <tag>
"Tags" the current database state for future rollback.
-
tagExists <tag>
Checks whether the given tag already exists.
-
validate
Checks the changelog for errors.
-
calculateCheckSum
-
executeSql
Parameters:
-
sql
Sql to execute
-
sqlFile
Sql file to execute
-
delimiter
-
-
-
-
-## Required Parameters for most commands ##
-
-
-
Option
Description
-
--changeLogFile=<path and filename>
The changelog file to use.
-
--username=<value>
Database username.
-
--password=<value>
Database password.
-
--url=<value>
Database JDBC URL.
-
--driver=<jdbc.driver.ClassName>
Database driver class name.
-
-
-
-## Optional Parameters ##
-
-
-
Option
Description
-
--classpath=<value>
Classpath containing migration files and JDBC Driver.
-
-
-## Using a liquibase.properties file ##
-
-If you do not want to always specify options on the command line, you can create a [properties file](config_properties.html) that contains default values. By default, Liquibase will look for a file called "liquibase.properties" in the current working directory, but you can specify an alternate location with the `--defaultsFile` flag. If you have specified an option in a properties file and specify the same option on the command line, the value on the command line will override the properties file value.
-
-
-## Examples ##
-
-### Standard Update Run ###
-
-{% highlight bat %}
-java -jar liquibase.jar \
- --driver=oracle.jdbc.OracleDriver \
- --classpath=\path\to\classes:jdbcdriver.jar \
- --changeLogFile=com/example/db.changelog.xml \
- --url="jdbc:oracle:thin:@localhost:1521:oracle" \
- --username=scott \
- --password=tiger \
- update
-{% endhighlight %}
-
-### Run update pulling changelogs from a .WAR file ###
-
-{% highlight bat %}
-java -jar liquibase.jar \
- --driver=oracle.jdbc.OracleDriver \
- --classpath=website.war \
- --changeLogFile=com/example/db.changelog.xml \
- --url=jdbc:oracle:thin:@localhost:1521:oracle \
- --username=scott \
- --password=tiger \
- update
-{% endhighlight %}
-
-### Run update pulling changelogs from an .EAR file ###
-
-{% highlight bat %}
-java -jar liquibase.jar \
- --driver=oracle.jdbc.OracleDriver \
- --classpath=application.ear \
- --changeLogFile=com/example/db.changelog.xml \
- --url=jdbc:oracle:thin:@localhost:1521:oracle \
- --username=scott \
- --password=tiger \
- update
-{% endhighlight %}
-
-### Don't execute changesets, save SQL to /tmp/script.sql ###
-
-{% highlight bat %}
-java -jar liquibase.jar \
- --driver=oracle.jdbc.OracleDriver \
- --classpath=jdbcdriver.jar \
- --url=jdbc:oracle:thin:@localhost:1521:oracle \
- --username=scott \
- --password=tiger \
- updateSQL > /tmp/script.sql
-{% endhighlight %}
-
-### List locks on the database change log lock table ###
-
-{% highlight bat %}
-java -jar liquibase.jar \
- --driver=oracle.jdbc.OracleDriver \
- --classpath=jdbcdriver.jar \
- --url=jdbc:oracle:thin:@localhost:1521:oracle \
- --username=scott \
- --password=tiger \
- listLocks
-{% endhighlight %}
-
-### Runs Liquibase using defaults from ./liquibase.properties ###
-
-{% highlight bat %}
-java -jar liquibase.jar update
-{% endhighlight %}
-
-#### liquibase.properties
-
-{% highlight properties %}
-driver: oracle.jdbc.OracleDriver
-classpath: jdbcdriver.jar
-url: jdbc:oracle:thin:@localhost:1521:oracle
-username: scott
-password: tiger
-{% endhighlight %}
-
-### Export Data from Database ###
-This will export the data from the targeted database and put it in a folder "data" in a file name specified with <insert file name>.
-
-{% highlight bat %}
-java -jar liquibase.jar --changeLogFile="./data/ " --diffTypes="data" generateChangeLog
-{% endhighlight %}
-
-### Update passing changelog parameters ###
-{% highlight bat %}
-liquibase.bat update -Dengine=myisam
-{% endhighlight %}
-
-# Unicode #
-### MySQL ###
-Add url parameters useUnicode=true and characterEncoding=UTF-8 to set character encoding to utf8.
-
-_Since v5.1.3 Connector/J now auto-detects servers configured with character_set_server=utf8mb4 or treats the Java encoding utf-8 passed using characterEncoding=... as utf8mb4._
-
-{% highlight bat %}
---url="jdbc:mysql://localhost/dbname?useUnicode=true&characterEncoding=UTF-8
-{% endhighlight %}
-
-more information about [MySQL Connector J Using Character Sets and Unicode](http://dev.mysql.com/doc/connector-j/en/connector-j-reference-charsets.html)
-
diff --git a/documentation/config_properties.md b/documentation/config_properties.md
deleted file mode 100644
index 64633750f..000000000
--- a/documentation/config_properties.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-layout: default
-title: Docs | Creating and Configuring liquibase.properties File
----
-# Creating and Configuring a liquibase.properties File
-
-
-
-Creating a *liquibase.properties* file allows you to store properties that don't change often in a *liquibase.properties* file. You can also use parameters to specify your database connection information so Liquibase can access your database and save you the trouble of passing along command line arguments.
-
-#### Creating the File
-To create a *liquibase.properties* file, generate a new text file in your project Liquibase directory and name it *liquibase.properties*.
-
-> Note: The file can also be named something other than liquibase.properties and/or be in a completely different directory by using the --defaultsFile parameter during runtime.
-To learn more please see [Liquibase Command Line](command_line.html).
-
-## Parameters
-The most common properties that you might set in the *liquibase.properties* are listed below. Any parameter that could be specified on
-the command line can also be specified in the properties file. If a parameter is specified in both the properties file and the command line,
-the command line value will override the value in the file.
-
-| Parameter | Definition |
-| --------- | ---------- |
-| changeLogFile | The path for your changelog file|
-| driver | The driver class name for your source database|
-| url | The primary database when doing an update, or the source database for performing comparisons. |
-| username | The username for your source database.|
-| password | The password for your source database.|
-| referenceDriver | The driver class name for your target database. |
-| referenceUrl | The database you want to use to compare to your source database. Also known as your target. |
-| referenceUsername | The username for your target database. |
-| referencePassword | The password for your target database. |
-| liquibaseProLicenseKey | Your Liquibase Pro license key (If you have one). |
-| classpath | The path for your database driver |
-| parameter.[parameter name] | Define global [change log parameter](changelog_parameters.html). E.g. parameter.table.name: tableA
-
-Different commands require different parameter information to work. For more information on parameter requirements, search the Liquibase Command topics in the knowledge base.
-
-## liquibase.properties File Example
-{% highlight text %}
-changeLogFile: ../path/to/file/dbchangelog.xml
-driver: oracle.jdbc.OracleDriver
-url: jdbc:oracle:thin:@192.168.0.22:1521/orcl
-username: PRO
-password: password
-referenceDriver: oracle.jdbc.OracleDriver
-referenceUrl: jdbc:oracle:thin:@192.168.0.22:1521/orcl
-referencePassword: password
-liquibaseProLicenseKey: aeioufakekey32aeioufakekey785463214
-classpath: ../path/to/file/ojdbc6-11.2.0.3.0.jar
-{% endhighlight %}
-
-
-### Advanced configuration options
-
-| Parameter | Definition |
-| --------- | ---------- |
-| includeCatalogInSpecification | boolean Should Liquibase include the catalog name when determining equality? |
-| convertDataTypes | boolean Should Liquibase convert to/from STANDARD data types. Applies to both snapshot and update commands. Default= true|
-
-### See Also ###
-* [Using a liquibase.properties file in the command line](command_line.html#using-a-liquibaseproperties-file)
-* [Using a liquibase.properties file with the maven plugin](maven/index.html#using-configuration-property-files)
diff --git a/documentation/contexts.md b/documentation/contexts.md
deleted file mode 100644
index cbb65ca53..000000000
--- a/documentation/contexts.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-layout: default
-title: Docs | Contexts
----
-
-# Contexts #
-
-"Contexts" in Liquibase are expressions you can add to changeSets to control which will be executed in any particular migration run.
-Any string can be used for the context name and they are checked case-insensitively.
-
-When you run the migrator though any of the available methods, you can pass in a set of contexts to run. Only changeSets marked with the passed contexts will be run.
-
-If you don't assign a context to a changeSet, it will run all the time, regardless of what contexts you pass in to the migrator.
-
-If you do not specify a context when you run the migrator, ALL contexts will be run.
-
-Here is an example of a change set using the context attribute:
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-## Context Syntax ##
-
-Contexts can be specified using AND, OR, ! and parentheses. Without parentheses the order of operations are "!" then "AND" then "OR".
-
-__Examples:__
-
- * context="!test"
- * context="v1.0 or map"
- * context="v1.0 or map"
- * context="!qa and !master"
-
- Using a "," to separate contexts works like an OR operation but with the highest precedence.
-
- __Examples:__
-
- * "test, qa" is the same as "test OR qa"
- * "test, qa and master" is the same as "(test) OR (qa and master)
-
-__Availability:__
-
-* "," separator available in all versions of Liquibase
-* "AND, OR, !, parentheses" added in 3.2.0
-
-
-## Using Contexts for Test Data ##
-
-If you are managing your test data with Liquibase, the best way to include it is in-line with all your other changeSets, but marked with a "test" context.
-That way, when you want your test data inserted you can run the migrator with the "test" context. When it comes time to migrate your production database,
-don't include the "test" context, and your test data will not be included (bare in mind that if you do not specify any context at all, every changeset will
-be applied, including those marked with a "test" context). If you have multiple test environments or test data sets, simply tag them with different contexts
-such as "min-test", "integration-test", etc.
-
-Using contexts to control test data is better than having a separate changeLog tree because later refactorings and changes will be applied to existing test
-data the same as they are applied to production data. If you had a set of test data that was created and simply added after the database is set up, you
-would be constantly manually updating your test data scripts to keep them in line with the current database schema.
-
-## Using Contexts for Multi-DBMS Change Logs ##
-
-You can use contexts to control which change sets run on which databases, but the better option is to use the built-in "dbms" tag on the changeSet tag.
-
-
-## Default context ##
-
-Beginning with Liquibase 3.5, you can specify a context attribute in the root databaseChangeLog node to assign that context to all changeSets in the changelog by default.
-
-The specified context will be AND'ed with any contexts specified in changeSets within the changelog file.
-
-## Include/IncludeAll context ##
-
-Beginning with Liquibase 3.5, you can specify a context attribute in `` or `` tags. If specified, the given context is added to all changeSets in the included file(s).
-
diff --git a/documentation/core-concepts/index.md b/documentation/core-concepts/index.md
deleted file mode 100644
index 65d4c08b1..000000000
--- a/documentation/core-concepts/index.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-layout: default
-title: Docs | Core Concepts Home
-subnav: subnav_documentation.md
-includeDaticalBox: true
----
-# Liquibase Core Concepts
-Performing database schema migrations is an essential task for nearly every software project. Learn some basic concepts of Liquibase, like changesets, how to use different formats for your changelog, and how different tables work. You can also learn more about intermediate-level concepts like parameters and how to use preconditions.
-
-## Liquibase Basics
-- Overview of how to run Liquibase
- - Running Liquibase from the Command Line
- - Running Liquibase from Ant
- - Running Liquibase from Maven
-- The changelog - master list of all the changes to your database
- - XML Format
- - YAML Format
- - JSON Format
- - SQL Format
- - Other Formats
-- Change Sets - how changes are organized in the changelog
-- DATABASECHANGELOG table - how changes are tracked in each database
-- DATABASECHANGELOGLOCK table - how Liquibase prevents duplicate executions
-
-## Liquibase Intermediate
-- Changelog Parameters - customizing the changelog at update time.
-- Making changes to your schema - Refactoring Commands
-- Using the include tag to break up your changelog
-- Using the includeAll tag to use directories full of XML or SQL
-- Contexts - limiting which changesets are deployed
-- Labels - limiting which changesets are deployed
-
-- Preconditions
-
diff --git a/documentation/creating-liquibase-projects-with-maven-postgreSQL.md b/documentation/creating-liquibase-projects-with-maven-postgreSQL.md
deleted file mode 100644
index 95a259fe3..000000000
--- a/documentation/creating-liquibase-projects-with-maven-postgreSQL.md
+++ /dev/null
@@ -1,118 +0,0 @@
----
-layout: default
-title: Docs | Creating Liquibase Project with Maven and PostgreSQL
----
-
-# Setting up a Liquibase project with Maven and PostgreSQL
-
-The purpose of this document is to guide you through the process of creating a new Maven project with
-PostgreSQL on a Linux/Unix/Mac machine. In this tutorial, you will generate an example project and follow
-the instructions to apply and learn concepts associated with creating new Liquibase Projects within Maven.
-
-## Prerequisites
-[Install Liquibase with Maven on Linux/Unix/Mac](installation-linux-unix-mac-with-maven.html) if you have not done so already.
-
-## Maven – Liquibase Project Tutorial
-To create a Liquibase project within Maven that uses a PostgreSQL database, begin with the following steps:
-1. Create a new project folder and name it `MavenPostgreSQL`.
-2. Create a new plain-text file named `dbchangelog.xml` in the `MavenPostgeSQL` directory. This file will be your *changelog*, a file that will keep track of
- all the changes you make to your database structure. You can learn more about them on the [Database Change Log File](databasechangelog.html) page.
- In this tutorial, you will manually add a single change. We will start with an empty changelog file.
-3. Open the `dbchangelog.xml` file and update it with the following text. This is a basic empty changelog file.
-
- {% highlight xml %}
-
-
-
- {% endhighlight %}
-
-{:start="4"}
-4. Create another plain text file in the same directory, named `liquibase.properties`
-5. Edit the liquibase.properties file to add the following properties:
- {% highlight txt %}
- changeLogFile: dbchangelog.xml
- url: jdbc:postgresql://localhost:5432/MYDATABASE
- username: postgres
- password: password
- {% endhighlight %}
- **Note:** If you have a [Liquibase Pro]() key and want to apply it to your project, add the following property to your liquibase.properties file.
- `liquibaseProLicenseKey: `
-
-{:start="6"}
-6. Add a changeset to the changelog.
- In the dbchangelog.xml file line 9 to 20 add a new changeset. This changeset will have one change in it, to create a table named "department".
-
- {% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- {% endhighlight %}
-
-{:start="7"}
-7. Now, we create the maven POM file for the project. Create a new plain-text file in the same directory named `pom.xml`.
-8. Edit the `pom.xml` file and update it to have the following contents:
-
- {% highlight xml %}
-
- 4.0.0
-
- com.my-group.app
- LiquiPostgreSQL-app
- 1.0-SNAPSHOT
-
-
-
-
- org.liquibase
- liquibase-maven-plugin
- 3.8.0
-
- liquibase.properties
-
-
-
- postgresql
- postgresql
- 9.1-901-1.jdbc4
-
-
-
-
-
-
-
- {% endhighlight %}
-
-{:start="9"}
-9. Open the command prompt and navigate to the `MavenPostgreSQL` directory.
-10. Run the following command: `mvn liquibase:update`
-11. From a database UI Tool, for example: "pgAdmin" check your database changes under "MYDATABASE".
- You should see a new "department" table added to the database.
-
-Also, you should see two more tables:
-
-1. DATABASECHANGELOG - This table keeps a record of all the changesets that have been deployed. The next time you run the **update** command, the
-changesets in the changelog will be compared with the DATABASECHANGELOG tracking table, and only the new changesets not
-found in the DATABASECHANGELOG will be deployed. You will notice that a new row was created in that table with the changeset
-information we have just deployed.
-2. DATABASECHANGELOGLOCK - This table is used internally by Liquibase to manage access to the changelog table during deployment.
diff --git a/documentation/databasechangelog.md b/documentation/databasechangelog.md
deleted file mode 100644
index 2b7e626ff..000000000
--- a/documentation/databasechangelog.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-layout: default
-title: Docs | Databasechangelog
----
-
-# Database Change Log File
-
-The root of all Liquibase changes is the databaseChangeLog file.
-
-## Available Attributes ##
-
-
-
Attribute
Description
-
logicalFilePath
Use to override the file name and path when creating the unique identifier of change sets. Required when moving or renaming change logs.
-
objectQuotingStrategy
This controls how object names are quoted in the SQL generated or used in calls to the database. Different databases do different things to
-the names of objects, for example Oracle converts everything to uppercase (unless quoted). There are three possible values. The default value is LEGACY.
-LEGACY - Same behavior as in Liquibase 2.0
-QUOTE_ALL_OBJECTS - Every object gets quoted. e.g. person becomes "person".
-QUOTE_ONLY_RESERVED_WORDS - Quote reserved keywords and invalid column names.
-
-
-## Available nested elements ##
-
-
-
Tag
Description
-
preConditions
Pre-conditions required to execute the change log. Read More
-
property
Value to set property to, if not set by another means. Read More
Additional files containing change sets to execute. Read More
-
context
Context to be appended (using AND) to all changeSets since 3.5
-
-
-When the Liquibase migrator runs, it parses the databaseChangeLog tag. It first checks any preconditions specified. If any of the [preconditions](preconditions.html) fail, the Liquibase will exit with an error message explaining what failed. Preconditions are useful for both documenting and enforcing expectations and assumptions of the changelog writer such as the DBMS to be run against or the user the changes are run as.
-
-If all preconditions are met, Liquibase will then begin running [changeSet](changeset.html) and [include](include.html) tags **in the order they appear in the databaseChangeLog file**.
-
-The XML schema for the databaseChangeLog tag is available at:
-
-* [http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.8.xsd](http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.8.xsd) **Since 3.1**
-
-Some legacy XSDs are listed on [the XML Format page](xml_format.html).
-
-Each changeSet contains an "id" tag and an "author" tag. These tags, along with the classpath location and name of the XML file create a unique identifier for that changeSet.
-
-## Sample Empty Change Log ##
-
-
-
-
diff --git a/documentation/databasechangelog_table.md b/documentation/databasechangelog_table.md
deleted file mode 100644
index c8ef9b700..000000000
--- a/documentation/databasechangelog_table.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-layout: default
-title: Docs | DatabaseChangeLog Table
----
-
-# DATABASECHANGELOG table
-
-Liquibase uses the `DATABASECHANGELOG` table to track which changeSets have been run.
-
-The table tracks each changeSet as a row, identified by a combination of the "id", "author", and "filename" columns.
-
-There is no primary key on the table. This is to avoid any database-specific restrictions on key lengths. The composite of "id", "author", and "filename"
-is unique across all rows of the table.
-
-
-
Column
Standard Data Type
Description
-
ID
VARCHAR(255)
Value from the changeSet "id" attribute
-
AUTHOR
VARCHAR(255)
Value from the changeSet "author" attribute
-
FILENAME
VARCHAR(255)
Path to the changelog. This may be an absolute path or a relative path depending on how the changelog
- was passed to Liquibase. For best results, it should be a relative path. The `logicalFilePath` attribute can be used
- [on the changelog](/documentation/databasechangelog.html) or [on individual changeSets](/documentation/changeset.html).
-
DATEEXECUTED
DATETIME
Date/time of when the changeSet was executed. Used with ORDEREXECUTED to determine rollback order
-
ORDEREXECUTED
INT
Order that the changeSets were executed. Used in addition to DATEEXECUTED to ensure order is correct even when the databases datetime supports poor resolution.
NOTE: The values are only guaranteed to be increasing within an individual update run. There are times where they will restart at zero.
-
EXECTYPE
VARCHAR(10)
Description of how the changeSet was executed. Possible values include "EXECUTED", "FAILED", "SKIPPED", "RERAN", and "MARK_RAN"
-
MD5SUM
VARCHAR(35)
Checksum of the changeSet when it was executed. Used on each run to ensure there have been no unexpected changes to changeSet in the changelog file.
-
DESCRIPTION
VARCHAR(255)
Short auto-generated human readable description of changeSet
-
COMMENTS
VARCHAR(255)
Value from the changeSet "comment" attribute
-
TAG
VARCHAR(255)
Tracks which changeSets correspond to tag operations.
-
LIQUIBASE
VARCHAR(20)
Version of Liquibase used to execute the changeSet
-
CONTEXTS
VARCHAR(255)
Context(s) used to execute the changeSet
-
LABELS
VARCHAR(255)
Label(s) used to execute the changeSet
-
DEPLOYMENT_ID
VARCHAR(10)
Changesets deployed together will have the same unique identifier
-
-
-
diff --git a/documentation/databasechangeloglock_table.md b/documentation/databasechangeloglock_table.md
deleted file mode 100644
index 1d40bf651..000000000
--- a/documentation/databasechangeloglock_table.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-layout: default
-title: Docs | DatabaseChangeLogLock Table
----
-
-# DATABASECHANGELOGLOCK table
-
-Liquibase uses the DATABASECHANGELOGLOCK table ensure only one instance of Liquibase is running at one time.
-
-Because Liquibase simply reads from the [DATABASECHANGELOG](databasechangelog_table.html) table to determine which changeSets need to run, if multiple instances of Liquibase are executed against the same database concurrently you will get conflicts.
-This can happen if multiple developers use the same database instance or if there are multiple servers in a cluster which auto-run Liquibase on startup.
-
-
-
Column
Standard Data Type
Description
-
ID
INT
Id of the lock. Currently there is only one lock, but is available for future use
-
LOCKED
INT
Set to "1" if the Liquibase is running against this database. Otherwise set to "0"
-
LOCKGRANTED
DATETIME
Date and time that the lock was granted
-
LOCKEDBY
VARCHAR(255)
Human-readable description of who the lock was granted to.
-
-
-### Notes
-
-If Liquibase does not exit cleanly, the lock row may be left as locked. You can clear out the current lock by running `liquibase releaseLocks` which runs `UPDATE DATABASECHANGELOGLOCK SET LOCKED=0`
-
diff --git a/documentation/dbdoc.md b/documentation/dbdoc.md
deleted file mode 100644
index 729b1cdd9..000000000
--- a/documentation/dbdoc.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-layout: default
-title: Docs | Dbdoc
----
-
-# Database Documentation Generator #
-
-Using change information stored in the change logs and an existing database, Liquibase can generate database change documentation.
-
-## Running DBDoc ##
-
-The dbDoc command support is currently available through the [command line](command_line.html) only.
-
-## Example ##
-
-{% highlight sh %}
-liquibase.sh --driver=oracle.jdbc.OracleDriver \
- --url=jdbc:oracle:thin:@testdb:1521:test \
- --username=bob \
- --password=bob \
- --changeLogFile=path/to/changelog.xml
- dbDoc \
- /docs/dbdoc
-{% endhighlight %}
-
-## Sample Output ##
-
-The documentation output is based on a "JavaDoc" style documentation. The report of changes from our sample changelog is available [here](http://www.liquibase.org/dbdoc/index.html).
diff --git a/documentation/diff.md b/documentation/diff.md
deleted file mode 100644
index 3ebf54bf2..000000000
--- a/documentation/diff.md
+++ /dev/null
@@ -1,239 +0,0 @@
----
-layout: default
-title: Docs | Diff Command
----
-# Liquibase Commands: diff
-The `diff` command in Liquibase allows you to compare two databases of the same type or different types to one another.
-
-## Uses
-The `diff` command is typically used at the completion of a project, because it allows you to verify all expected changes are in the changelog. The `diff` command is also useful for the following tasks:
-+ Finding missing objects in your database
-+ Seeing that a change was made to your database
-+ Finding unexpected items in your database
-
-## Running the diff Command
-To compare two databases:
-+ The first option is to run the `diff` command and pass the parameters needed for your source database and target database. For example:
-Run the following:
-{% highlight bash %}
-liquibase
---outputFile=mydiff.txt
---driver=oracle.jdbc.OracleDriver
---classpath=ojdbc14.jar
---url="jdbc:oracle:thin:@::"
---username=
---password=
-diff
---referenceUrl="jdbc:oracle:thin:@::"
---referenceUsername=
---referencePassword=
-{% endhighlight %}
-
-See the [snapshot command documentation](/documentation/snapshot.html) for an example of using a snapshot file as one of the databases being used in the command.
-
->**Note:** When running `diff` against two different databases, the class path property should reference both .jar files. Use the path separator that is correct
-for your operating system (a semicolon on Windows, a colon on Mac or Linux). Example: `classpath: ojdbc7.jar:postgresql-42.2.8.jar`
-
-+ Alternatively, configure the *liquibase.properties* file to include your driver class path, URL, and user authentication information for both databases.
-Run the following command:
-{% highlight bash %}
-liquibase --outputFile=mydiff.txt diff
-{% endhighlight %}
->**Note:** For information on how to configure your *liquibase.properties* file, view the [Creating & Configuring your *liquibase.properties* File](config_properties.html) topic in the knowledge base.
-
-
-Example Output
-
-{% highlight text %}
-
-Diff Results:
-Reference Database: MYSCHEMA2 @ jdbc:oracle:thin:@localhost:1521:ORCL (Default Schema: MYSCHEMA2)
-Comparison Database: MYSCHEMA @ jdbc:oracle:thin:@localhost:1521:ORCL (Default Schema: MYSCHEMA)
-Compared Schemas: MYSCHEMA2 -> MYSCHEMA
-Product Name: EQUAL
-Product Version: EQUAL
-Missing Catalog(s): NONE
-Unexpected Catalog(s): NONE
-Changed Catalog(s): NONE
-Missing Check Constraint(s): NONE
-Unexpected Check Constraint(s): NONE
-Changed Check Constraint(s): NONE
-Missing Column(s): NONE
-Unexpected Column(s):
- MYSCHEMA.DEPARTMENT.ACTIVE
- MYSCHEMA.SERVICETECH.ACTIVE
- MYSCHEMA.SERVICETECH2.ACTIVE
- MYSCHEMA.SERVICETECH3.ACTIVE
- MYSCHEMA.VIEW1.ACTIVE
- MYSCHEMA.DATABASECHANGELOG.AUTHOR
- MYSCHEMA.DATABASECHANGELOG.COMMENTS
- MYSCHEMA.DATABASECHANGELOG.CONTEXTS
- MYSCHEMA.DATABASECHANGELOG.DATEEXECUTED
- MYSCHEMA.DATABASECHANGELOG.DEPLOYMENT_ID
- MYSCHEMA.DATABASECHANGELOG.DESCRIPTION
- MYSCHEMA.DATABASECHANGELOG.EXECTYPE
- MYSCHEMA.DATABASECHANGELOG.FILENAME
- MYSCHEMA.DATABASECHANGELOG.ID
- MYSCHEMA.DATABASECHANGELOGLOCK.ID
- MYSCHEMA.DEPARTMENT.ID
- MYSCHEMA.SERVICETECH.ID
- MYSCHEMA.SERVICETECH2.ID
- MYSCHEMA.SERVICETECH3.ID
- MYSCHEMA.VIEW1.ID
- MYSCHEMA.DATABASECHANGELOG.LABELS
- MYSCHEMA.DATABASECHANGELOG.LIQUIBASE
- MYSCHEMA.DATABASECHANGELOGLOCK.LOCKED
- MYSCHEMA.DATABASECHANGELOGLOCK.LOCKEDBY
- MYSCHEMA.DATABASECHANGELOGLOCK.LOCKGRANTED
- MYSCHEMA.DATABASECHANGELOG.MD5SUM
- MYSCHEMA.DEPARTMENT.NAME
- MYSCHEMA.SERVICETECH.NAME
- MYSCHEMA.SERVICETECH2.NAME
- MYSCHEMA.SERVICETECH3.NAME
- MYSCHEMA.VIEW1.NAME
- MYSCHEMA.DATABASECHANGELOG.ORDEREXECUTED
- MYSCHEMA.DATABASECHANGELOG.TAG
-Changed Column(s): NONE
-Missing Database Package(s): NONE
-Unexpected Database Package(s): NONE
-Changed Database Package(s): NONE
-Missing Database Package Body(s): NONE
-Unexpected Database Package Body(s): NONE
-Changed Database Package Body(s): NONE
-Missing Foreign Key(s): NONE
-Unexpected Foreign Key(s): NONE
-Changed Foreign Key(s): NONE
-Missing Function(s): NONE
-Unexpected Function(s): NONE
-Changed Function(s): NONE
-Missing Index(s): NONE
-Unexpected Index(s):
- PK_DATABASECHANGELOGLOCK UNIQUE ON MYSCHEMA.DATABASECHANGELOGLOCK(ID)
- PK_DEPARTMENT UNIQUE ON MYSCHEMA.DEPARTMENT(ID)
- PK_SERVICETECH UNIQUE ON MYSCHEMA.SERVICETECH(ID)
- PK_SERVICETECH2 UNIQUE ON MYSCHEMA.SERVICETECH2(ID)
- PK_SERVICETECH3 UNIQUE ON MYSCHEMA.SERVICETECH3(ID)
-Changed Index(s): NONE
-Missing Java Class(s): NONE
-Unexpected Java Class(s): NONE
-Changed Java Class(s): NONE
-Missing Java Source(s): NONE
-Unexpected Java Source(s): NONE
-Changed Java Source(s): NONE
-Missing Primary Key(s): NONE
-Unexpected Primary Key(s):
- PK_DATABASECHANGELOGLOCK on MYSCHEMA.DATABASECHANGELOGLOCK(ID)
- PK_DEPARTMENT on MYSCHEMA.DEPARTMENT(ID)
- PK_SERVICETECH on MYSCHEMA.SERVICETECH(ID)
- PK_SERVICETECH2 on MYSCHEMA.SERVICETECH2(ID)
- PK_SERVICETECH3 on MYSCHEMA.SERVICETECH3(ID)
-Changed Primary Key(s): NONE
-Missing Sequence(s): NONE
-Unexpected Sequence(s): NONE
-Changed Sequence(s): NONE
-Missing Stored Procedure(s): NONE
-Unexpected Stored Procedure(s): NONE
-Changed Stored Procedure(s): NONE
-Missing Synonym(s): NONE
-Unexpected Synonym(s): NONE
-Changed Synonym(s): NONE
-Missing Table(s): NONE
-Unexpected Table(s):
- DATABASECHANGELOG
- DATABASECHANGELOGLOCK
- DEPARTMENT
- SERVICETECH
- SERVICETECH2
- SERVICETECH3
-Changed Table(s): NONE
-Missing Trigger(s): NONE
-Unexpected Trigger(s): NONE
-Changed Trigger(s): NONE
-Missing Unique Constraint(s): NONE
-Unexpected Unique Constraint(s): NONE
-Changed Unique Constraint(s): NONE
-Missing View(s): NONE
-Unexpected View(s):
- VIEW1
-Changed View(s): NONE
-Liquibase command 'diff' was executed successfully.
-
-{% endhighlight %}
-
-
-
-The `diff` command produces a list of categories along with one of the following descriptions:
-+ **Missing:** The object is not on your comparison database (source database).
-+ **Unexpected:** There are objects on your comparison database (source database) that are not on your reference database (target database).
-+ **Changed:** The object as it exists on the source database is different than as it exists in the target database.
-> **Note:** The changed description will not specify the type of change applied to your database. Run the [diffChangeLog](diffChangeLog.html) command
-to generate a changelog that will apply the changes to the target database.
-
-Liquibase Community `diff` categories:
-+ Catalog
-+ Column
-+ Foreign Key
-+ Index
-+ Primary Key
-+ Schema
-+ Sequence
-+ Procedure
-+ Unique Constraints
-+ View
-
-Liquibase Pro `diff` categories:
-
-+ Check Constraint
-+ Package
-+ Package Body
-+ Function
-+ Trigger
-+ Synonyms
->**Note:** Liquibase does not currently check Datatype length.
-
-## Filtering diff Types
-Liquibase allows you to use diffType parameters to filter the types of objects you want to compare. Multiple filters can be added
-to the parameter as a comma separated list. If no diffTypes are specified, all objects are considered.
-
-
-Example:
-{% highlight bash %}
-liquibase --diffTypes=tables,indexes,views diff
-{% endhighlight %}
-
-
-Example filtered output
-
-{% highlight text %}
-
-Diff Results:
-Reference Database: MYSCHEMA2 @ jdbc:oracle:thin:@localhost:1521:ORCL (Default Schema: MYSCHEMA2)
-Comparison Database: MYSCHEMA @ jdbc:oracle:thin:@localhost:1521:ORCL (Default Schema: MYSCHEMA)
-Compared Schemas: MYSCHEMA2 -> MYSCHEMA
-Product Name: EQUAL
-Product Version: EQUAL
-Missing Index(s): NONE
-Unexpected Index(s):
- PK_DATABASECHANGELOGLOCK UNIQUE ON MYSCHEMA.DATABASECHANGELOGLOCK(ID)
- PK_DEPARTMENT UNIQUE ON MYSCHEMA.DEPARTMENT(ID)
- PK_SERVICETECH UNIQUE ON MYSCHEMA.SERVICETECH(ID)
- PK_SERVICETECH2 UNIQUE ON MYSCHEMA.SERVICETECH2(ID)
- PK_SERVICETECH3 UNIQUE ON MYSCHEMA.SERVICETECH3(ID)
-Changed Index(s): NONE
-Missing Table(s): NONE
-Unexpected Table(s):
- DATABASECHANGELOG
- DATABASECHANGELOGLOCK
- DEPARTMENT
- SERVICETECH
- SERVICETECH2
- SERVICETECH3
-Changed Table(s): NONE
-Missing View(s): NONE
-Unexpected View(s):
- VIEW1
-Changed View(s): NONE
-Liquibase command 'diff' was executed successfully.
-
-{% endhighlight %}
-
diff --git a/documentation/diffChangeLog.md b/documentation/diffChangeLog.md
deleted file mode 100644
index e5ee0d81b..000000000
--- a/documentation/diffChangeLog.md
+++ /dev/null
@@ -1,153 +0,0 @@
----
-layout: default
-title: Docs | diffChangeLog Command
----
-
-# Liquibase Commands: diffChangeLog
-The `diffChangeLog` command provides you with:
-+ Information containing differences between two databases; specifically, the `diffChangeLog` command points out the differences in general and generates changes to resolve most of them.
-+ A *changelog* file containing deployable *changeSets*.
-
-## Uses
-The `diffChangeLog` command is typically used when you want to create a deployable *changelog* to synchronize multiple databases. The `diffChangeLog` command also provides more information about:
-+ Missing objects in your database
-+ Changes made to your database
-+ Unexpected items in your database
-
-## Running the diffChangeLog Command
-To create a diff *changelog*:
-
-+ The first option is to run the `diffChangeLog` command and pass the parameters needed for your source database and target database.
-
-As an example you can run the following:
-
-{% highlight bash %}
-liquibase
---changeLogFile=dbchangelog.xml
---outputFile=mydiff.txt
---driver=oracle.jdbc.OracleDriver
---classpath=ojdbc14.jar
---url="jdbc:oracle:thin:@::"
---username=
---password=
-diffChangeLog
---referenceUrl="jdbc:oracle:thin:@::"
---referenceUsername=
---referencePassword=
-{% endhighlight %}
-
-See the [snapshot command documentation](/documentation/snapshot.html) for an example of using a snapshot file as one of the databases being used in the command.
-
->**Note:** When running `diffChangeLog` against two different databases, the class path property should reference both .jar files. Use the path separator that is correct for your operating system (a semicolon on Windows, a colon on Mac or Linux). Example: `classpath: ojdbc7.jar:postgresql-42.2.8.jar`
-
-+ Alternatively, configure the *liquibase.properties* file to include your driver class path, URL, and user authentication information for both databases. Run the following command:
-
-{% highlight bash %}
-
-liquibase --changeLogFile=file_name.xml diffChangeLog
-
-{% endhighlight %}
-
-> **Note:** Replace *file_name.xml*, with your filename and extension format. If you specify a file name that already exists, Liquibase will append your changes to the existing file.
-
-For information on how to configure your *liquibase.properties* file, view the [Creating & Configuring your *liquibase.properties* File](config_properties.html) topic in the knowledge base.
-
-## Output
-The `diffChangeLog` command produces a list of all *Objects* and creates a *changelog* with a list of *changeSets*.
-
-Liquibase Community `diffChangeLog` categories:
-- Catalog
-- Column
-- Foreign Key
-- Index
-- Primary Key
-- Schema
-- Sequence
-- Procedure
-- Unique Constraints
-- View
-
-### Example
-
-
-Console Output Example
-
-{% highlight text %}
-
-Liquibase Pro 3.8.1 by Datical licensed to Liquibase Pro Customer
-Liquibase command 'diffChangeLog' was executed successfully.
-
-{% endhighlight %}
-
-
-
-## Additional Functionality with Liquibase Pro
-While Liquibase Community stores all *changeSets* in a *changelog*, Liquibase Pro creates a directory called *Objects* and places the directory at the same level as your *changelog*. The *Objects* directory contains a subdirectory for each of the following stored logic types:
-- checkconstraint
-- package
-- packagebody
-- function
-- trigger
-- synonyms
-
->**Note:** that not all database platforms support all of these types.
-
-### Example
-
-
-Pro diffChangeLog sample file
-
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-
-> **Note:** Liquibase does not currently check datatype length.
diff --git a/documentation/existing_project.md b/documentation/existing_project.md
deleted file mode 100644
index 4ad6d06ba..000000000
--- a/documentation/existing_project.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-layout: default
-title: Docs | Starting Liquibase on an Existing project
----
-
-# Adding Liquibase on an Existing project
-
-The [Quick Start Guide](/quickstart.html) works well for starting Liquibase on a new project because your empty changelog file matches your empty database.
-However, when you have an existing project with an existing database things are more complicated.
-
-Unfortunately, there is no simple "this is how you do it" answer because there is so much variations in projects, processes and requirements.
-Liquibase provides many tools to help the process, but it is up to you to decide the best way to combine them for your particular situation.
-
-When adding Liquibase to an existing project there are basically two approaches: "Make it look like you've always been using Liquibase" and "Just start using Liquibase"
-
-## Make it look like you've always been using Liquibase
-
-The goal of this approach is to have a changelog file that matches the current state of your database. You can run this changeLog against a blank database and the final result will be indistinguishable from your existing databases--as if you used Liquibase from the beginning.
-This approach is usually the best long term, but it can be more work up front.
-
-#### Create ChangeLog
-Creating the changelog to match your database can be done automatically using the [generateChangeLog command](generating_changelogs.html) or be done manually.
-For any database larger than a few tables, the generateChangeLog command is usually a good idea but make sure you go through the generated changeSets to ensure they are correct. Liquibase does not always detect more complex structures like stored procedures or details like if an index is not clustered. Also, ensure data types are as you expected them.
-
-#### Populate the DatabaseChangeLog table
-Once you have your changeLog, you need a way to ensure that the pre-Liquibase changeSets are only ran on new, empty databases. The easiest way to do this is generally to use the `changeLogSync` or `changeLogSyncSQL` command to execute (or generate) the SQL that marks the starting changeSets as already ran without actually executing them.
-
-As an alternative to the changeLogSync command, you can add [contexts](contexts.html) on the pre-Liquibase changeSets such as `` and when you run Liquibase on a new database you run with `liquibase --contexts=legacy update` and on an existing database you run with `liquibase --contexts=non-legacy`.
-
-Finally, you can add `` tags to the generated changeSets. For example, if you have a `` changeSet, you would add `` tag.
-Adding preconditions requires more changes to the changeLog file and introduces a performance penalty because Liquibase must check the database metadata for each changeSet the first run through, this approach is usually best used in isolated cases only.
-
-#### What is the current state?
-Often times a part of the reason to move to Liquibase is because your schemas have diverged over time, so an important question to answer is "If I'm making the changelog file match the current state, what **is** the current state?"
-Usually the best answer to that question is "the production database" but it can vary.
-
-How divergent your schemas are will also affect which of the above techniques you use to populate the DatabaseChangeLog table, and it will often times make sense to use multiple approaches.
-For example, you may want to generate your base changeLogs from the production database and use changeLogSyncSQL to be able to mark them ran on everything from production down.
-Then you can add your non-released changeSets to the changeLog file with a precondition checking if it has already ran. That will allow Liquibase to automatically figure out the correct state for all your databases from development through production.
-
-
-## We are going to use Liquibase starting.....NOW!
-
-Instead of building up a changeLog to match your existing database, you can instead just declare "from now on we are using Liquibase".
-The advantage to this is that it much easier to set up because it is just a mandate.
-Usually this works best going from one version to the next because your databases are all in a reasonably consistent state and you simply start tracking database changes in your next version using Liquibase.
-Because Liquibase only looks at the DatabaseChangeLog table to determine what needs to run, it doesn't care what else might be in your database and so it will leave all your existing tables alone and just run the new changeSets.
-
-The biggest disadvantage to this approach is that you cannot bootstrap an empty database with Liquibase alone. A work-around is to take a pre-Liquibase snapshot using your database backup tool and use that as your database seed.
-Any time you need to create a new database, you first load in the seed and then run Liquibase update.
-
-Depending on how much variation you have between your schemas, even with this approach you may need to rely on preconditions or a "mark changes ran" script in order to standardize and handle those variations.
-
-
-## People and Processes
-
-Finally, remember that starting to use Liquibase--especially on an existing project--isn't just about how you bootstrap your changeLog file. It is also a question of how you introduce Liquibase into your existing processes and culture.
-
-For many companies and projects, everyone realizes the problems that need fixing and are on board with the advantages of change.
-For others, however, there can be entrenched interests and strong resistance similar to any other process change.
-Liquibase provides many tools and approaches that can be used to ease it into an existing process such as [SQL output](sql_output.html), [SQL formatted changelogs](sql_format.html), [diffChangeLog](diff.html) and more that can be combined
-in ways that works best for your group.
-
-If you know that introducing Liquibase is going to be complex, either from a technical or processes standpoint, it is usually best to introduce it slowly.
-Start with it on a new project as a trial run and once you have a good grasp of how it works and available options, apply it to other existing projects.
-
-If you want help getting a project set up, check out [Liquibase Pro](https://support.liquibase.org/), which includes support.
diff --git a/documentation/generate-sql-update-schemas.md b/documentation/generate-sql-update-schemas.md
deleted file mode 100644
index b742c8530..000000000
--- a/documentation/generate-sql-update-schemas.md
+++ /dev/null
@@ -1,416 +0,0 @@
----
-layout: side-search
-title: Docs | Generating SQL
-subnav: subnav_quickstart.md
-includeDaticalBox: true
----
-
-# Generating SQL to Update Database Schemas
-
-
-
-There are two reasons you would want to generate SQL in Liquibase.
-1. You need to know exactly what is being done to your database.
-2. Your company policies prevent you from using Liquibase in certain environments.
-
-Generating SQL can be helpful when you want to update your database schemas, but want to view those database changes before applying them. There are several commands that generate deployable SQL, these are:
-
-## updateSQL Command
-Running the `updateSQL` command tells Liquibase to evaluate all the changesets in your *changelog*, then generates the corresponding SQL for what will be deployed to the database so you can preview the changes.
-
-To use the `updateSQL` command, type the following into your command prompt:
-
-{% highlight bash %}
-
-liquibase --changeLogFile=mssql_lbpro_master_changelog.xml updateSQL
-
-{% endhighlight %}
-
-
-
-SQL Output Example
-{% highlight SQL%}
--- *********************************************************************
--- Update Database Script
--- *********************************************************************
--- Change Log: mssql_lbpro_master_changelog_no_catalog.xml
--- Ran at: 11/15/19 1:56 PM
--- Against: datical_login@jdbc:sqlserver://3.219.82.47:1433;sslProtocol=TLS;jaasConfigurationName=SQLJDBCDriver;statementPoolingCacheSize=10;serverPreparedStatementDiscardThreshold=10;enablePrepareOnFirstPreparedStatementCall=false;fips=false;socketTimeout=0;authentication=NotSpecified;authenticationScheme=nativeAuthentication;xopenStates=false;sendTimeAsDatetime=true;trustStoreType=JKS;trustServerCertificate=false;TransparentNetworkIPResolution=true;serverNameAsACE=false;sendStringParametersAsUnicode=true;selectMethod=direct;responseBuffering=adaptive;queryTimeout=-1;packetSize=8000;multiSubnetFailover=false;loginTimeout=15;lockTimeout=-1;lastUpdateCount=true;encrypt=false;disableStatementPooling=false;databaseName=proCatalog;columnEncryptionSetting=Disabled;applicationName=Microsoft JDBC Driver for SQL Server;applicationIntent=readwrite;
--- Liquibase version: 3.8.2-DAT-3598-SNAPSHOT
--- *********************************************************************
-
-USE proCatalog;
-GO
-
--- Lock Database
-UPDATE DATABASECHANGELOGLOCK SET LOCKED = 1, LOCKEDBY = 'Erzsebet-PC (192.168.0.34)', LOCKGRANTED = '2019-11-15T13:56:05.17' WHERE ID = 1 AND LOCKED = 0
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::3::dropSynonym-proCatalog::Liquibase Pro User
-DROP SYNONYM [privateSynonymOnTable]
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('3::dropSynonym-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 17, '8:82a49a1df297832e0e5c014c7dba5d97', 'dropSynonym synonymName=privateSynonymOnTable', '', 'EXECUTED', NULL, 'dropprivatesynonym,lbl-syn', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::4::dropPublicSynonym::Liquibase Pro User
-DROP SYNONYM [publicSynonymOnTable]
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('4::dropPublicSynonym', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 18, '8:e46072543816816b16fff4fdded56068', 'dropSynonym synonymName=publicSynonymOnTable', '', 'EXECUTED', NULL, 'droppublicsynonym,lbl-syn', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::2::dropView-proCatalog::Liquibase Pro User
-DROP VIEW persons_view
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('2::dropView-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 19, '8:6b7030bf90f5164b6f261814d4180ade', 'dropView viewName=persons_view', '', 'EXECUTED', NULL, 'dropview,lbl-view', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::2::dropProc-proCatalog::Liquibase Pro User
-DROP PROCEDURE printHelloWorld
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('2::dropProc-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 20, '8:b8e93c02e6d2ba004261da39c7a7b578', 'dropProcedure procedureName=printHelloWorld', '', 'EXECUTED', NULL, 'dropprocedure,lbl-proc', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::2::rollbackFunction-proCatalog::Liquibase Pro User
-USE [proCatalog2]
-GO
-
-CREATE FUNCTION [dbo].[emailFunction]()
-RETURNS VARCHAR(100)
-AS
-BEGIN
-DECLARE @rtEmail VARCHAR
-SET @rtEmail='random@datical.com'
-RETURN @rtEmail
-END
-GO
-
-USE [proCatalog2]
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('2::rollbackFunction-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 21, '8:ae8e2abb341cf5fce706d5a69deb3387', 'sql; createFunction functionName=emailFunction; sql', '', 'EXECUTED', NULL, 'rollbackfunction,lbl-func', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::2::dropFunc-proCatalog::Liquibase Pro User
-DROP FUNCTION emailFunction
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('2::dropFunc-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 22, '8:7b7e55cacd71d5affda392508f3cb17a', 'dropFunction functionName=emailFunction', '', 'EXECUTED', NULL, 'dropfunction,lbl-func', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::3::disableTrigger-proCatalog::Liquibase Pro User
-DISABLE TRIGGER table_trigger ON primary_table
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('3::disableTrigger-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 23, '8:b16d51e844e972a72f45809a9b7b8336', 'disableTrigger tableName=primary_table, triggerName=table_trigger', '', 'EXECUTED', NULL, 'disabletrigger,lbl-trig', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::4::enableTrigger-proCatalog::Liquibase Pro User
-ENABLE TRIGGER table_trigger ON primary_table
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('4::enableTrigger-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 24, '8:780e362d158fe05bf9617a86b2b8f6d9', 'enableTrigger tableName=primary_table, triggerName=table_trigger', '', 'EXECUTED', NULL, 'enabletrigger,lbl-trig', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::5::renameTrigger-proCatalog::Liquibase Pro User
-sp_rename 'proCatalog.table_trigger', 'table_trigger_deux'
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('5::renameTrigger-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 25, '8:916bb9a6ced89805b4c2a946d7a62496', 'renameTrigger newTriggerName=table_trigger_deux, oldTriggerName=table_trigger', '', 'EXECUTED', NULL, 'renametrigger,lbl-trig', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::6::dropCatalogTrigger-proCatalog::Liquibase Pro User
-DROP TRIGGER db_trigger
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('6::dropCatalogTrigger-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 26, '8:2deca539397c8a4d5b42c5c2c60b2fd8', 'dropTrigger triggerName=db_trigger', '', 'EXECUTED', NULL, 'dropcatalogtrigger,lbl-trig', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::7::dropTrigger-proCatalog::Liquibase Pro User
-DROP TRIGGER table_trigger_deux
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('7::dropTrigger-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 27, '8:e3dd925e4c1d8c5da328726d092945ec', 'dropTrigger triggerName=table_trigger_deux', '', 'EXECUTED', NULL, 'droptrigger,lbl-trig', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::4::dropCC-proCatalog::Liquibase Pro User
-ALTER TABLE Persons DROP CONSTRAINT chk_Person
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('4::dropCC-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 28, '8:bdcd47644f81e75b61649c57adf9817a', 'dropCheckConstraint constraintName=chk_Person, tableName=Persons', '', 'EXECUTED', NULL, 'dropcheckconstraint,lbl-cc', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::namespaceDatical::Datical (generated)
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID, TAG) VALUES ('namespaceDatical', 'Datical (generated)', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 29, '8:d7f6cfe3454adb7c8f76de668dfc091e', 'tagDatabase', '', 'EXECUTED', NULL, 'namespacetest', '3.8.2-DAT-3598-SNP', '3847767930', 'namespaceTest')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::namespaceAppdba::addCC-proCatalog::Liquibase Pro User
-ALTER TABLE [Persons] ADD CONSTRAINT [chk_Person] CHECK (([P_Id]>(0) AND [City]='Austin'))
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('namespaceAppdba::addCC-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 30, '8:5e664002fca240883e6728a3078023a4', 'addCheckConstraint constraintName=chk_Person, tableName=Persons', '', 'EXECUTED', NULL, 'namespacetest', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::namespaceFunction::createFunction-proCatalog::Liquibase Pro User
-CREATE FUNCTION [dbo].[emailFunction]()
-RETURNS VARCHAR(100)
-AS
-BEGIN
-DECLARE @rtEmail VARCHAR
-SET @rtEmail='random@datical.com'
-RETURN @rtEmail
-END
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('namespaceFunction::createFunction-proCatalog', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 31, '8:bfdb067647d26bce7755de59000a2440', 'createFunction functionName=emailFunction', '', 'EXECUTED', NULL, 'namespacetest', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::1::columnOrder123-PROSCHEMA::Liquibase Pro User
-CREATE TABLE COLUMN_ORDER (COLUMN1 varchar(20), COLUMN2 varchar(20), COLUMN3 varchar(20))
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('1::columnOrder123-PROSCHEMA', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 32, '8:1f702550fb575ee944eabf8261565651', 'createTable tableName=COLUMN_ORDER', '', 'EXECUTED', NULL, 'urldb', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Changeset mssql_lbpro_master_changelog_no_catalog.xml::1::columnOrder231-PROSCHEMA::Liquibase Pro User
-CREATE TABLE column_order (column2 varchar(20), column3 varchar(20), column1 varchar(20))
-GO
-
-INSERT INTO DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('1::columnOrder231-PROSCHEMA', 'Liquibase Pro User', 'mssql_lbpro_master_changelog_no_catalog.xml', GETDATE(), 33, '8:39f420962f02a3a1d0ec2f2548b628ad', 'createTable tableName=column_order', '', 'EXECUTED', NULL, 'refurldb', '3.8.2-DAT-3598-SNP', '3847767930')
-GO
-
--- Release Database Lock
-UPDATE DATABASECHANGELOGLOCK SET LOCKED = 0, LOCKEDBY = NULL, LOCKGRANTED = NULL WHERE ID = 1
-GO
-
-{% endhighlight%}
-
-
-
-## updateSQL Command with the Labels Parameter
-The `updateSQL` command allows you to also run a `--labels` parameter to determine which changesets in the *changelog* to evaluate based on its label. You can view your labels in your *changelog*
-
-
-Changelog Example
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- supplier_id BETWEEN 100 and 9999
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-
-To use the `updateSQL` command with the labels parameter, type the following into your command prompt:
-{% highlight bash %}
-
-liquibase --changeLogFile=changelog.xml --outputFile=updateSql.txt --labels=setup updateSQL
-
-{% endhighlight %}
-
-
-
-SQL Output Example
-The following is an example of the `updateSQL` command output with the labels parameter enabled:
-
-{% highlight sql %}
-
--- *********************************************************************
--- Update Database Script
--- *********************************************************************
--- Change Log: changelog.xml
--- Ran at: 11/12/19 3:48 PM
--- Against: jenkinsci@jdbc:postgresql://localhost:5432/jenkinsci
--- Liquibase version: 3.8.1-local-SNAPSHOT
--- *********************************************************************
-
--- Create Database Lock Table
-CREATE TABLE public.databasechangeloglock (ID INTEGER NOT NULL, LOCKED BOOLEAN NOT NULL, LOCKGRANTED TIMESTAMP WITHOUT TIME ZONE, LOCKEDBY VARCHAR(255), CONSTRAINT DATABASECHANGELOGLOCK_PKEY PRIMARY KEY (ID));
-
--- Initialize Database Lock Table
-DELETE FROM public.databasechangeloglock;
-
-INSERT INTO public.databasechangeloglock (ID, LOCKED) VALUES (1, FALSE);
-
--- Lock Database
-UPDATE public.databasechangeloglock SET LOCKED = TRUE, LOCKEDBY = '172.18.0.1 (172.18.0.1)', LOCKGRANTED = '2019-11-12 15:48:30.445' WHERE ID = 1 AND LOCKED = FALSE;
-
--- Create Database Change Log Table
-CREATE TABLE public.databasechangelog (ID VARCHAR(255) NOT NULL, AUTHOR VARCHAR(255) NOT NULL, FILENAME VARCHAR(255) NOT NULL, DATEEXECUTED TIMESTAMP WITHOUT TIME ZONE NOT NULL, ORDEREXECUTED INTEGER NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35), DESCRIPTION VARCHAR(255), COMMENTS VARCHAR(255), TAG VARCHAR(255), LIQUIBASE VARCHAR(20), CONTEXTS VARCHAR(255), LABELS VARCHAR(255), DEPLOYMENT_ID VARCHAR(10));
-
--- Changeset changelog.xml::1::createTableforSynonym-proschema::Liquibase Pro User
-CREATE TABLE "proschema"."primary_table" ("name" CHAR(20));
-
-INSERT INTO public.databasechangelog (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('1::createTableforSynonym-proschema', 'Liquibase Pro User', 'changelog.xml', NOW(), 1, '8:2e63963bef0a14594b566e06c3eabe2d', 'createTable tableName=primary_table', '', 'EXECUTED', NULL, 'setup', '3.8.1-local-SNP', '3595312173');
-
--- Changeset changelog.xml::2::createTableforView-proschema::Liquibase Pro User
-CREATE TABLE "proschema"."account" ("acct_num" numeric(20, 0), "amoount" numeric(10, 2));
-
-INSERT INTO public.databasechangelog (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('2::createTableforView-proschema', 'Liquibase Pro User', 'changelog.xml', NOW(), 2, '8:344a50de118d3db500c0b28b76e14e81', 'createTable tableName=account', '', 'EXECUTED', NULL, 'setup', '3.8.1-local-SNP', '3595312173');
-
--- Changeset changelog.xml::3::createTableforCC-proschema::Liquibase Pro User
-CREATE TABLE "proschema"."suppliers" ("supplier_id" numeric(4, 0), "supplier_name" VARCHAR(50));
-
-INSERT INTO public.databasechangelog (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('3::createTableforCC-proschema', 'Liquibase Pro User', 'changelog.xml', NOW(), 3, '8:19236a09a645a2fecd0707b7e3efe4c1', 'createTable tableName=suppliers', '', 'EXECUTED', NULL, 'setup', '3.8.1-local-SNP', '3595312173');
-
--- Changeset changelog.xml::4::functionForTrigger::Liquibase Pro User
-SET SEARCH_PATH=proschema;
-
-CREATE OR REPLACE FUNCTION "proschema".canned_spam()
- RETURNS trigger
- SET SCHEMA 'proschema'
- AS $$
- BEGIN
- RAISE NOTICE 'Canned Spam in a frying pan: ick';
- RETURN NEW;
- END ;
- $$
-LANGUAGE plpgsql;
-
-INSERT INTO public.databasechangelog (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('4::functionForTrigger', 'Liquibase Pro User', 'changelog.xml', NOW(), 4, '8:d26a1492fbf2b697a634dad498a87096', 'createFunction functionName=canned_spam', '', 'EXECUTED', NULL, 'setup', '3.8.1-local-SNP', '3595312173');
-
--- Release Database Lock
-UPDATE public.databasechangeloglock SET LOCKED = FALSE, LOCKEDBY = NULL, LOCKGRANTED = NULL WHERE ID = 1;
-
-{% endhighlight %}
-
-
-
-## futureRollbackSQL Command
-The `futureRollbackSQL` command generates SQL that reverses changes you applied while using the `updateSQL` command.
-
-To run the `futureRollbackSQL` command, type the following into your command prompt:
-
-{% highlight bash %}
-
-liquibase --changeLogFile=mssql_lbpro_master_changelog_no_catalog.xml futureRollbackSQL
-
-{% endhighlight %}
-
-
-SQL Output Example
-
-{% highlight text %}
-Coming Soon
-{% endhighlight %}
-
-
-
-
-#### Note for Liquibase Pro Users
-Liquibase Pro allows users to also produce deployable SQL for Stored Logic. If you are a Liquibase Pro user, and you are trying to run the `futureRollbackSQL` command, make sure you add a `` tag to your changesets so you output the correct SQL, like so:
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-{% endhighlight %}
\ No newline at end of file
diff --git a/documentation/generating_changelogs.md b/documentation/generating_changelogs.md
deleted file mode 100644
index 2c87789ba..000000000
--- a/documentation/generating_changelogs.md
+++ /dev/null
@@ -1,154 +0,0 @@
----
-layout: default
-title: Docs | Generating changelogs
----
-
-# Liquibase Commands: generateChangeLog
-
-
-
-
-The `generateChangeLog` command creates a *changelog* file that has a sequence of *changeSets* which describes how to re-create the current state of the database.
-
-## Uses
-The `generateChangeLog` command is typically used when you want to capture the current state of a database, then apply those changes to any number of databases.
-
-> **Note:** When using the [update command](update.html) to apply the changes in the *changelog*, Liquibase will not create a new database or schema. You must create them ***before*** applying the *changelog* to it.
-
-## Running the generateChangeLog command
-To generate a *changelog*:
-1. Configure the *liquibase.properties* file to include your driver class path, URL, and user authentication information for the database you want to capture.
-
-> **Note:** For information on how to configure your *liquibase.properties* file, view the [Creating & Configuring your liquibase.properties File](config_properties.html) topic in the knowledge base. Instead of using a liquibase.properties file, you can also pass the necessary information on the command line.
-
-2. Open your command prompt or Linux terminal and run the following command:
-
-{% highlight bash %}
-
-liquibase --changeLogFile=dbchangelog.xml generateChangeLog
-
-{% endhighlight %}
-
-## Output
-
-The `generateChangeLog` command generates a *changelog* that contains all of your *Objects* (represented as *changeSets*) and places the file in the same directory where the command was ran.
-
-The extension provided determines the format of the *changelog*, so if you specify the filename as `changelog.xml` you will get an XML formatted *changelog*. However, if you specify the filename as `changelog.yaml` or `changelog.json` or `changelog.postgresql.sql` you will get *changelogs* formatted in YAML or JSON or SQL, respectively.
-
->**Note:** When generating an SQL formatted changelog, you must specify the short name of the targeted database type as part of the filename (as shown above).
-
-### Example
-
-Liquibase Community changelog
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-
-
-## Additional Functionality with Liquibase Pro
-While Liquibase Community stores all *changeSets* in a *changelog*, Liquibase Pro creates a directory called *Objects* and places the directory at the same level as your *changelog*. The *Objects* directory contains a subdirectory for each of the following stored logic types.
-- package
-- packagebody
-- function
-- storedprocedure
-- trigger
-- view
-
->**Note:** Not all database platforms support all of these types.
-
-### Example
-
-
-Liquibase Pro changelog
-
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
diff --git a/documentation/grails.md b/documentation/grails.md
deleted file mode 100644
index a5f1550d0..000000000
--- a/documentation/grails.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-layout: default
-title: Docs | Grails
----
-
-# Using Liquibase with Grails
-
-Liquibase works great with Grails projects.
-
-
-To learn more about using Liquibase in a Grails project, check out [the Grails database-migration plugin.](https://plugins.grails.org/plugin/grails/database-migration)
diff --git a/documentation/hibernate.md b/documentation/hibernate.md
deleted file mode 100644
index b425e0ef5..000000000
--- a/documentation/hibernate.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: default
-title: Docs | Hibernate
----
-
-# Using Liquibase with Hibernate
-
-Liquibase works great with Hibernate. Support is provided through an extension, which
-allows you to use your Hibernate configuration as a comparison database for diff, diffChangeLog and generateChangeLog.
-
-To learn more about using Liquibase and Hibernate together, check out the [liquibase-hibernate extension at GitHub](https://github.com/liquibase/liquibase-hibernate) or
-in the [liquibase-hibernate extension wiki](https://github.com/liquibase/liquibase-hibernate/wiki)
diff --git a/documentation/include.md b/documentation/include.md
deleted file mode 100644
index ece7f614c..000000000
--- a/documentation/include.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-layout: default
-title: Docs | Include tag
----
-# Include Tag
-
-The include tag allows you to break up your change-logs into more manageable pieces. To easily include multiple files, use the [includeAll](includeall.html) tag.
-
-{% highlight xml %}
-
-
-
-
-
-
-{% endhighlight %}
-
-As projects grow, the number of changeSets in a changeLog can grow unwieldy. To help ease this problem,
-and to make management of changes easier, databaseChangeLogs can be included to create a tree of change-logs.
-In the example above, the root change log includes first the changes in `com/example/news/news.changelog.xml` then
-the changes in `com/example/directory/directory.changelog.xml`.
-
-Included change-logs are run in the order they are found so care does need to be taken to make sure that the included
-changelogs are either completely independent, or that any required changelogs are run first.
-
-Any [preconditions](preconditions.html) defined at the changelog level in sub changelog files will be evaluated *before* any changesets are ran.
-
-The reason to use the `` tag rather than using XML's built-in include functionality is that
-with the built-in functionality the parser sees just one big XML document. Liquibase needs to uniquely identify each changeset with
-the id, the author, and the file name. By using the `` and `` tags Liquibase makes it so you only have to
-ensure that the id/author combinations are unique *within each file*, not across all change logs.
-
-## Available Attributes
-
-
-
Attribute
Description
-
file
Name of the file to import required
-
relativeToChangelogFile
Is the file path relative to the changelog file containing the element rather than to the classpath. Defaults to "false" since 1.9
-
context
Append context (using AND) to all contained changeSets since 3.5
-
-
-
-## Implementation Notes
-
-Currently there is no checking for looping changelogs or double inclusion of changelogs.
-
-If you include a changelog twice, you shouldn't run into problems because the second time around, Liquibase will know that the changeSets
-have been run and won't run them again (even if there is a runAlways tag).
-
-If you create a changeLog loop (root.changelog.xml includes news.changelog.xml which includes root.changelog.xml) you will get
-an infinite loop. Checks for loops is a feature on our list of enhancements, but is currently not implemented.
diff --git a/documentation/includeall.md b/documentation/includeall.md
deleted file mode 100644
index a0cc2984a..000000000
--- a/documentation/includeall.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-layout: default
-title: Docs | includeAll tag
----
-
-# includeAll Tag
-
-The includeAll tag allows you to break up your change-logs into more manageable pieces. It is similar to the [include](include.html) tag, but instead of passing a particular changelog file to include, you specify a directory and it will include all *.xml files as changelog files, and all *.sql files as individual changes. All files that are found are run in order according to alphabetical order.
-
-## Sample ##
-{% highlight xml %}
-
-
-
-
-
-{% endhighlight %}
-
-## Warnings ##
-**While the includeAll tag has many valuable uses, its use can cause problems down the road. The biggest thing to avoid is to use
-the includeAll tag to simulate Ruby on Rails Active Migrations strategy of a list of changes, one per file, that are ran in file order.
-While this seems like a good idea at first, it [quickly runs into problems](http://www.liquibase.org/2007/06/the-problem-with-rails-active-migrations.html)**
-
-If you do choose to use the includeAll tag, make sure you have a naming strategy in place that will insure that you will never have conflicts or need to rename files to change to force a reordering.
diff --git a/documentation/index.md b/documentation/index.md
deleted file mode 100644
index cf2f5fc8f..000000000
--- a/documentation/index.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-layout: default
-title: Docs | Documentation Home
-subnav: subnav_documentation.md
-includeDaticalBox: true
----
-
-
Liquibase Documentation
-
-
-### Learn about tracking, deploying & versioning your databases with Liquibase!
-
-
-
-
diff --git a/documentation/installation-linux-unix-mac-with-maven.md b/documentation/installation-linux-unix-mac-with-maven.md
deleted file mode 100644
index 77e2dc62d..000000000
--- a/documentation/installation-linux-unix-mac-with-maven.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-layout: default
-title: Docs | Installing Liquibase with Maven on Linux/Unix/Mac
----
-
-# Installing Liquibase with Maven on Linux/Unix/Mac
-
-To download Maven, navigate to [https://maven.apache.org/download.cgi](https://maven.apache.org/download.cgi) and click
-on the **For Linux/Unix/Mac** Binary tar.gz download file to install the latest version of Apache Maven.
-
-## Installing
-Once you have downloaded the tar.gz file, extract it to a new local directory on your computer (**Example:**
-`/usr/apps/apache-maven-3.6.2`), then add the maven-3.6.2/bin directory to your PATH.
-To add the directory to your PATH:
-1. Open the Terminal or Linux Command Line.
-2. Run the following command: `export PATH=$PATH:/usr/apps/apache-maven-3.6.2/bin`
-
-**Note:** This command will not permanently update your PATH for the remainder of the session. To permanently update your
-PATH edit your `~/.profile` or `~/.bashrc` file and add the `export` command as shown above, and then run either `source ~/.profile` or `source ~/.bashrc`
-
-## Verifying
-Verification is an essential aspect of the Maven installation process, and there are three things you need to check:
-1. The maven-3.6.2/bin folder was correctly added to your PATH.
-2. Java is installed on your system.
-3. You can run Maven itself.
-
-### Verification #1: Check your Path
-To verify that you have correctly added the maven-3.6.2/bin folder to your PATHs, type `env` in your Terminal or Linux command to display
-all your available PATHs. Verify that the pat you added is shown.
-
-### Verification #2: Check for Java Installation
-For Maven to run correctly, Java must be installed on your Linux/Unix/Mac machine. To verify that Java is installed on your computer:
-1. Open your Terminal or Linux Command.
-2. In the Command Prompt window, type: `java -version`
-If you see the error `-bash: java: command not found`, then you need to either install Java, or you need to add the location of the Java executable to your PATH.
-To install Java on your computer:
-1. Navigate to [https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html](https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html)
-and install the Java JDK.
-2. Add the location of the Java file to your PATH environment as a variable.
-
-### Verification #3: Run maven
-Finally, verify that Maven is working correctly. To run the command:
-1. Open your Terminal or Linux Command.
-2. In the Command Prompt window, type: `mvn –v`
-3. You should see something like the output below:
-{% highlight txt %}
-Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-27T17:06:16+02:00)
-Maven home: /opt/apache-maven-3.6.2
-Java version: 1.8.0_45, vendor: Oracle Corporation
-Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre
-Default locale: en_US, platform encoding: UTF-8
-OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"
-{% endhighlight %}
-
-## Next steps - using Liquibase in a Maven project
-
-Now that you have installed Maven, you can [set up a new Maven project and see how to use the Liquibase Maven plugin in that
-project.](creating-liquibase-projects-with-maven-postgreSQL.html)
diff --git a/documentation/installation-linux-unix-mac.md b/documentation/installation-linux-unix-mac.md
deleted file mode 100644
index c8ed7bbf0..000000000
--- a/documentation/installation-linux-unix-mac.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-layout: default
-title: Docs | Installing Liquibase Command Line Tool for Linux/Unix/Mac
----
-
-
-# Installing Liquibase Command Line for Linux/Unix/Mac #
-
-
-Once you have downloaded the [Liquibase-Version#-bin.tar.gz file](https://download.liquibase.org/download), create a local directory on your computer (**Example:** `/usr/apps/Liquibase--bin`), then add the directory to your PATH.
-To add the directory to your PATH:
-1. Open the Terminal or Linux Command Line.
-2. Run the following command: `export PATH=$PATH:/path/to/Liquibase--bin`
-
-This command will not permanently update your PATH after the termination of your session. To update your PATH permanently, run the following command: `source ~/.profile or source ~/.bashrc`
-
-Then restart your command line.
-
-> **Note for MacOS users only:** There is a more convenient way to set path using Terminal in Default mode.
-To set path you can run: `sudo nano /etc/paths` then append the path `/path/to/Liquibase--bin` at the end of the file. Hit `Ctrl+x` and `y` for yes, to save the file and restart your Terminal. View the [Downloading & Installing Liquibase on MacOS](https://www.youtube.com/watch?v=w5yiwdQ1U_E) video for more information.
-
-## Verifying ##
-
-Verification is an essential aspect of the Liquibase installation process, and there are three things you need to check:
-1. The Liquibase folder was correctly added to your PATH.
-2. Java is installed on your system.
-3. You can run the Liquibase help command.
-
-### Verification #1: Check your PATH ###
-
-To verify that you have correctly added the Liquibase folder to your PATHs, type `env` in your Terminal or Linux command to display all your available PATHs.
-
-### Verification #2: Check for Java Installation ###
-
-For Liquibase to run correctly, Java must be installed on your Linux/Mac/Unix machine. To verify that Java is installed on your computer:
-1. Open your Terminal or Linux Command Line.
-2. In the Command Prompt window, type: `java -version`
-
-If you see the error: `-bash: java: command not found`, then you need to either install Java, or you need to add the location of the Java executable to your PATH.
-To install Java on your computer
-1. Navigate to [https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html](https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html)
- and install the Java JDK.
-2. Add the location of the Java executable to your PATH.
-
-
-### Verification #3: Run the Liquibase Help Command ###
-
-Another way to verify that you installed Liquibase correctly on your computer is to run the Liquibase Help Command. To run the command:
-1. Open your Terminal or Linux Command.
-2. In the Command Prompt window, type: `liquibase --help`
-
-## Common Troubleshooting ##
-- If you cannot run the Liquibase Help command, verify that you have correctly installed Java. Also ensure that the Liquibase folder you downloaded is set to your PATHs.
-- If you have installed Java, but are still receiving an error, add Java to your PATHs using the steps provided in the **Installing** section.
diff --git a/documentation/installation-windows.md b/documentation/installation-windows.md
deleted file mode 100644
index e0b0d3e33..000000000
--- a/documentation/installation-windows.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-layout: default
-title: Docs | Installing Liquibase Command Line Tool for Windows
----
-
-# Installing Liquibase Command Line for Windows
-
-
-
-Once you have downloaded the [Liquibase-Version#-bin.zip file](https://download.liquibase.org/download/), right-click the zipped file and select **Extract All**. You can place the extracted folder, anywhere on your local drive. Before you can use Liquibase, you must set a Path System Variable to the folder on your computer.
-
-To set the Path System Variable:
-1. In your Windows Start Menu Search, type `env` and select the **Edit the System Environment** option in the Control Panel.
-2. In the System Properties Advanced tab, select **Environment Variables**.
-3. In the System Variables section, highlight the Path variable and click **Edit**.
-4. In the Edit environment variable window, select **New**, then add the path to the Liquibase-Version#-bin folder.
-
- **Example:** C:\apps\liquibase-3.8.1-bin
-
-5. Click **Ok** on all windows to close them.
-
-## Verifying
-
-Verification is an essential aspect of the Liquibase installation process, and there are three things you need to check:
-1. The Liquibase folder was correctly added to your Path System Variables.
-2. Java is installed on your system.
-3. You can run the Liquibase help command in PowerShell.
-
-### Verification #1: Check Path System Variables
-
-To verify that you have correctly added the Liquibase folder to your Path System Variables:
-1. In your Windows Start Menu Search, type `power` and select **Windows PowerShell**.
-2. In the PowerShell window, type: `$env:PATH`
-
-You should see the following:
-
-{:style="width: 100%;"}
-
-
-### Verification #2: Check for Java Installation
-
-For Liquibase to run correctly, Java must be installed on your Windows machine. To verify that Java is installed on your computer:
-1. In your Windows Start Menu Search, Type `cmd` to open the Command Prompt.
-2. In the Command Prompt window, type: `java.exe -version`
-If you see the error: `‘java.exe’ is not recognized as an internal or external command, operable program or batch file`, navigate to [https://www.java.com/en/download](https://www.java.com/en/download) to install Java.
-
-### Verification #3: Run the Liquibase Help Command
-
-Another way to verify that you installed Liquibase correctly on your computer is to run the Liquibase Help Command. To run the command:
-1. In your Windows Start Menu Search, Type `cmd` to open the Command Prompt.
-2. In the Command Prompt window, type: `liquibase --help`
-
-## Common Troubleshooting
-
-- If you cannot run the Liquibase Help command, verify that you have correctly installed Java. Also, ensure that the Liquibase folder you downloaded is set to your Path System Variables.
-- If you have installed Java, but are still receiving an error, add Java to your Path System Variables using the steps provided in the **Installing** section.
diff --git a/documentation/installation/index.md b/documentation/installation/index.md
deleted file mode 100644
index da958a726..000000000
--- a/documentation/installation/index.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-layout: default
-title: Docs | Installation Home
-subnav: subnav_documentation.md
-includeDaticalBox: true
----
-# Liquibase Installation
-Learn how to install Liquibase to help with database schema tracking, changes, and deployments. Select the type of Liquibase installation you’re looking for below.
-
-
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
The file to output the Migration SQL script to, if it exists it
-will be overwritten. Default value is: ${project.build.directory}/liquibase/migrate.sql.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
Generates a diff between the specified database and the
-reference database. The output is either a report or a changelog
-depending on the value of the diffChangeLogFile parameter.
-
-
Attributes:
-
-
-
-
Requires a Maven 2.0 project to be executed.
-
-
Requires dependency resolution of artifacts in scope: test.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
If this parameter is set, the changelog needed to "fix" differences
-between the two databases is output. If the file exists, it is
-appended to. If this is null, a comparison report is output to
-stdout.
List of diff types to include in Change Log expressed as a comma
-separated list from: tables, views, columns, indexes, foreignkeys,
-primarykeys, uniqueconstraints, data. If this is null then the
-default types will be: tables, views, columns, indexes,
-foreignkeys, primarykeys, uniqueconstraints
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The fully qualified name of the driver class to use to connect to
-the reference database. If this is not specified, then the
-driver will be used instead.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
If this parameter is set, the changelog needed to "fix" differences
-between the two databases is output. If the file exists, it is
-appended to. If this is null, a comparison report is output to
-stdout.
List of diff types to include in Change Log expressed as a comma
-separated list from: tables, views, columns, indexes, foreignkeys,
-primarykeys, uniqueconstraints, data. If this is null then the
-default types will be: tables, views, columns, indexes,
-foreignkeys, primarykeys, uniqueconstraints
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
The fully qualified name of the driver class to use to connect to
-the reference database. If this is not specified, then the
-driver will be used instead.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
The file to output the Rollback SQL script to, if it exists it will
-be overwritten. Default value is: ${project.build.directory}/liquibase/migrate.sql.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The date to rollback the database to. The format of the date must
-match either an ISO date format, or that of the
-DateFormat.getDateInstance() for the platform the
-plugin is executing on.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
The date to rollback the database to. The format of the date must
-match either an ISO date format, or that of the
-DateFormat.getDateInstance() for the platform the
-plugin is executing on.
Generates a changelog based on the current database schema.
-Typically used when beginning to use Liquibase on an existing
-project and database schema.
-
-
Attributes:
-
-
-
-
Requires a Maven 2.0 project to be executed.
-
-
Requires dependency resolution of artifacts in scope: test.
List of diff types to include in Change Log expressed as a comma
-separated list from: tables, views, columns, indexes, foreignkeys,
-primarykeys, uniqueconstraints, data. If this is null then the
-default types will be: tables, views, columns, indexes,
-foreignkeys, primarykeys, uniqueconstraints
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
List of diff types to include in Change Log expressed as a comma
-separated list from: tables, views, columns, indexes, foreignkeys,
-primarykeys, uniqueconstraints, data. If this is null then the
-default types will be: tables, views, columns, indexes,
-foreignkeys, primarykeys, uniqueconstraints
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
The number of changes to apply to the database. By default this
-value is 0, which will result in all changes (not already applied
-to the database) being applied. Default value is: 0.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The number of changes to apply to the database. By default this
-value is 0, which will result in all changes (not already applied
-to the database) being applied.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
Use LiquibaseUpdateSQL or Maven goal "updateSQL"
-instead.
-
-
Description:
-
-
Creates an SQL migration script using the provided
-DatabaseChangeLog(s) comparing what already exists in the database
-to what is defined in the DataBaseChangeLog(s).
-
-
Attributes:
-
-
-
-
Requires a Maven 2.0 project to be executed.
-
-
Requires dependency resolution of artifacts in scope: test.
The number of changes to apply to the database. By default this
-value is 0, which will result in all changes (not already applied
-to the database) being applied. Default value is: 0.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
The file to output the Migration SQL script to, if it exists it
-will be overwritten. Default value is: ${project.build.directory}/liquibase/migrate.sql.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The number of changes to apply to the database. By default this
-value is 0, which will result in all changes (not already applied
-to the database) being applied.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
Invokes Liquibase to rollback the database (and mark changesets
-as unapplied). The change sets to be rolled back are specified
-using attributes 'rollbackCount', 'rollbackTag' and/or
-'rollbackDate'
-
-
Attributes:
-
-
-
-
Requires a Maven 2.0 project to be executed.
-
-
Requires dependency resolution of artifacts in scope: test.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The date to rollback the database to. The format of the date must
-match either an ISO date format, or that of the
-DateFormat.getDateInstance() for the platform the
-plugin is executing on.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
The date to rollback the database to. The format of the date must
-match either an ISO date format, or that of the
-DateFormat.getDateInstance() for the platform the
-plugin is executing on.
Generates the SQL that is required to rollback the database
-using one or more of the specified attributes 'rollbackCount',
-'rollbackTag' and/or 'rollbackDate'
-
-
Attributes:
-
-
-
-
Requires a Maven 2.0 project to be executed.
-
-
Requires dependency resolution of artifacts in scope: test.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
The file to output the Rollback SQL script to, if it exists it will
-be overwritten. Default value is: ${project.build.directory}/liquibase/migrate.sql.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The date to rollback the database to. The format of the date must
-match either an ISO date format, or that of the
-DateFormat.getDateInstance() for the platform the
-plugin is executing on.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
The date to rollback the database to. The format of the date must
-match either an ISO date format, or that of the
-DateFormat.getDateInstance() for the platform the
-plugin is executing on.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
The number of changes to apply to the database. By default this
-value is 0, which will result in all changes (not already applied
-to the database) being applied. Default value is: 0.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The number of changes to apply to the database. By default this
-value is 0, which will result in all changes (not already applied
-to the database) being applied.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
The number of changes to apply to the database. By default this
-value is 0, which will result in all changes (not already applied
-to the database) being applied. Default value is: 0.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
The file to output the Migration SQL script to, if it exists it
-will be overwritten. Default value is: ${project.build.directory}/liquibase/migrate.sql.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The number of changes to apply to the database. By default this
-value is 0, which will result in all changes (not already applied
-to the database) being applied.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
The number of changes to apply to the database. By default this
-value is 0, which will result in all changes (not already applied
-to the database) being applied. Default value is: 0.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
Allows for the maven project artifact to be included in the class
-loader for obtaining the Liquibase property and DatabaseChangeLog
-files. Default value is: true.
Allows for the maven test output directory to be included in the
-class loader for obtaining the Liquibase property and
-DatabaseChangeLog files. Default value is: true.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive. Default value is: INFO.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on. Default value is: true.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file. Default value is: false.
The number of changes to apply to the database. By default this
-value is 0, which will result in all changes (not already applied
-to the database) being applied.
The Liquibase contexts to execute, which can be "," separated if
-multiple contexts are required. If no context is specified then ALL
-contexts will be executed.
The Liquibase labels to execute, which can be "," separated if
-multiple labels are required or a more complex expression. If no
-label is specified then ALL all will be executed.
Controls the level of logging from Liquibase when executing. The
-value can be "debug", "info", "warning", "severe", or "off". The
-value is case insensitive.
Controls the prompting of users as to whether or not they really
-want to run the changes on a database that is not local to the
-machine that the user is current executing the plugin on.
Flag allowing for the Liquibase properties file to override any
-settings provided in the Maven plugin configuration. By default if
-a property is explicity specified it is not overridden if it also
-appears in the properties file.
Controls the verbosity of the output from invoking the plugin.
-
-
-
-
Type: boolean
-
-
Required: No
-
-
Default: false
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/documentation/maven/index.md b/documentation/maven/index.md
deleted file mode 100644
index b50640089..000000000
--- a/documentation/maven/index.md
+++ /dev/null
@@ -1,251 +0,0 @@
----
-layout: default
-title: Docs | Maven
-subnav: subnav_maven.md
----
-
-# Maven Liquibase Plugin
-
-Liquibase can be controlled via a Maven plug-in which can be obtained from the central Maven repository.
-
-You can find all the versions of the Liquibase-core and Maven plugins in the central repository by going [here](http://mvnrepository.com/artifact/org.liquibase/liquibase-core).
-
-We recommend using Apache Maven 3.1.x or newer to make it easier to configure the log-level of Liquibase Maven Plugin with MAVEN_OPTs or by passing the following command:
-
-`-Dorg.slf4j.simpleLogger.defaultLogLevel=DEBUG`
-
-## Goals Available
-
-* [liquibase:changelogSync](maven_changelogsync.html)
-* [liquibase:changelogSyncSQL](maven_changelogsyncsql.html)
-* [liquibase:clearCheckSums](maven_clearchecksums.html)
-* [liquibase:dbDoc](maven_dbDoc.html)
-* [liquibase:diff](maven_diff.html)
-* [liquibase:dropAll](maven_dropall.html)
-* [liquibase:generateChangeLog](maven_generateChangeLog.html)
-* [liquibase:help](maven_help.html)
-* [liquibase:listLocks](maven_listlocks.html)
-* [liquibase:releaseLocks](maven_releaselocks.html)
-* [liquibase:rollback](maven_rollback.html)
-* [liquibase:rollbackSQL](maven_rollbacksql.html)
-* [liquibase:status](maven_status.html)
-* [liquibase:tag](maven_tag.html)
-* [liquibase:update](maven_update.html)
-* [liquibase:updateSQL](maven_updatesql.html)
-* [liquibase:updateTestingRollback](maven_updatetestingrollback.html)
-* [liquibase:futureRollbackSQL](maven_futurerollbacksql.html)
-* [liquibase:migrate](maven_migrate.html) **DEPRECATED** use update instead
-* [liquibase:migrateSQL](maven_migrate.html) **DEPRECATED** use updateSQL instead
-
-
-## Configuration and Usage
-
-Configuration of the plugin is done via the `` section of the `pom.xml`, specifying the configuration and execution phase to bind the plugin to.
-
-Each goal has its own configuration parameters, but some of which are common to other plugin goals, for more information on all the configuration parameters available for a specific goal click on the link to goal above.
-
-
-### Paths to files
-
-As of version 1.6.1.0 of the Maven plugin all files are resolved from the maven test classpath for the Maven project or an absolute path. This allows for [DatabaseChangeLogs](../databasechangelog.html) to be present in other Maven artifacts (on the classpath) and able to be used to invoke liquibase on a database.
-
-
-### Using Configuration Property Files
-
-Configuration settings for the Maven Liquibase plugin can be specified in standard Java Property files. If a [configuration property file](../config_properties.html) is specified it will be used to setup the properties for the invocation of the Maven Liquibase plugin.
-
-For each property defined in the file that matches a property in the goal being invoked that property of the goal will be set. If the property does not match any of the properties for the goal, then a warning will be displayed to the user, but execution will continue.
-
-The reason for only printing a warning is to allow a user to define a single master configuration property file that can be resused for multiple Maven Liquibase goals like [liquibase:update](maven_update.html) and [liquibase:tag](maven_tag.html).
-
-
-#### Using both a Configuration Property File and specifying Configuration Values
-
-It is possible to specify a Configuration Property File and individual Properties in the `` section of the Maven Liquibase plugin.
-
-If this is done the properties specified in the `` section will be used in preference over those defined in the properties file.
-
-If this behaviour is not desirable, then the properties file can be setup to override the specified properties in the `` section by adding the following to the `` section;
-
-{% highlight xml %}
-true
-{% endhighlight %}
-
-
-### Example of Maven Liquibase Update
-
-You need to ensure that you include the relevant JDBC driver for your database in the dependency section of Maven POM file.
-
-MySQL example:
-{% highlight xml %}
-
-
-
- mysql
- mysql-connector-java
-
- ${mysql-version}
-
-
-
-{% endhighlight %}
-
-Oracle example (thin driver):
-{% highlight xml %}
-
-
-
- com.oracle
- ojdbc14
- 10.2.0.4
-
-
-
-{% endhighlight %}
-
-
-The following is a sample configuration for the Liquibase Maven plugin, version 1.6.1.0, showing an example of the [liquibase:update](maven_update.html) goal;
-
-{% highlight xml %}
-
-
-
-
- org.liquibase
- liquibase-maven-plugin
-
- src/main/resources/liquibase/liquibase.properties
-
-
-
- process-resources
-
- update
-
-
-
-
-
-
-
-{% endhighlight %}
-
-This example configuration will execute the [liquibase:update](maven_update.html) goal as part of the process-resources phase of the build. The parameters (database url, password, etc...) for running Liquibase are specified in the `src/main/resources/liquibase.properties`.
-
->**Note:** The path to the file src/main/resources/liquibase.properties could be shortened to liquibase.properties if there was only one on the classpath.
-
-All the parameters for executing the Maven Liquibase plugin can also be specified in `` section of the plugin. Below is an example of this:
-
-{% highlight xml %}
-
- org.liquibase
- liquibase-maven-plugin
- 3.0.5
-
- src/main/resources/org/liquibase/business_table.xml
- oracle.jdbc.driver.OracleDriver
- jdbc:oracle:thin:@tf-appserv-linux:1521:xe
- liquibaseTest
- pass
-
-
-
- process-resources
-
- update
-
-
-
-
-{% endhighlight %}
-
-
-### Further configuration properties
-
-To disable the popup dialog that confirms migrations on non-local databases, add the following code snippet:
-
-`false`
-
-Use the following maven command to get hints about all available configuration parameters within the Liquibase maven plugin:
-
-`mvn help:describe -DgroupId=org.liquibase -DartifactId=liquibase-maven-plugin -Dversion=2.0.1 -Dfull=true`
-
-### Using a global configuration for multiple projects
-
-Through the usage of a parent-pom (some call it company super-pom) it is possible to have a centralized Liquibase plugin configuration that applies to all your Maven child projects. For a detailed explanation of the super-pom concept, see [Maven manual Pom section](http://maven.apache.org/guides/introduction/introduction-to-the-pom.html).
-
-In this setup, the plugin configuration is set in the super-pom, so that it becomes available to all child projects. The adaptation to each project needs (database driver, jdbc url, etc.) is made through a local `liquibase.properties` file. In addition, since several configurations may be necessary inside the project, `liquibase.properties` can be filtered by with the Maven resource filtering system.
-
-Parent `pom.xml` configuration:
-
-{% highlight xml %}
-
-
-
-
- org.liquibase
- liquibase-maven-plugin
- x.x.x.x
-
- true
- target/classes/liquibase.properties
-
-
-
-
-
-{% endhighlight %}
-
-You want to replace x.x.x.x by the most recent version of the plugin.
-
-As shown above, you may want to add an `` section, or put more configuration properties in the `` section. Keep in mind that any modification will apply to all child projects. It is possible to some extent to override this global configuration in your local `liquibase.properties` file as `` is set to `true`. If you have a few exceptions among your projects but want to keep a global config for all the others, you can always add the `` section to your child `pom.xml`. This will override the global config.
-
-The `liquibase.properties` must be put in the `src/main/resources` folder, as well as your `db.changelog.xml`. It can hold as many properties as you need. Here's an already quite complete example:
-
-{% highlight properties %}
-contexts: ${liquibase.contexts}
-changeLogFile: com/company/client/project/db.changelog.xml
-driver: ${dataSource.project.driverClass}
-url: ${dataSource.project.jdbcURL}
-username: ${dataSource.project.user}
-password: ${dataSource.project.password}
-verbose: true
-dropFirst: false
-{% endhighlight %}
-
-The placeholders are filtered by the Maven resource filtering system. In order to get your Maven standard `resources/` folder filtered you need to have this config in your `pom.xml`:
-
-{% highlight xml %}
-
-
-
- src/main/resources
- true
-
-
-
-{% endhighlight %}
-
-See [How do I filter resource files](http://maven.apache.org/guides/getting-started/index.html#How_do_I_filter_resource_files) for more details.
-
-In this particular setup, the project jdbc url, database driver, username and password are used for Liquibase as well.
-
-The placeholders are replaced by values found in filter property files located in `src/main/filters`.
-
-You can have as many property file filters as you need. To specify the filter to use on Maven execution, you need to use [Maven profiles](http://maven.apache.org/guides/introduction/introduction-to-profiles.html).
-
-A typical invocation would look like this:
-
-`mvn resources:resources liquibase:update -P`
-
-Invoking the `resources` is necessary in order to have the `liquibase.properties` placeholders filtered. The `-P` option tells Maven the profile to use and thus the set of values (from the filter properties file) to use for filtering.
-
-If you don't need the filtering capabilities, you can replace in the super-pom plugin configuration with the following:
-
-`target/classes/liquibase.properties by src/main/resources/liquibase.properties`
-
-Invocation is then simplified to a mere: `mvn liquibase:update`.
-
-The main advantages of this setup are:
-- No Liquibase plugin configuration in your projects. Only the `liquibase.properties` is required.
-- A unique place where to update the plugin version (you don't need to manuall edit all your `pom.xml` and commit them)
diff --git a/documentation/maven/maven-get-oracle-drivers.md b/documentation/maven/maven-get-oracle-drivers.md
deleted file mode 100644
index ecde4096a..000000000
--- a/documentation/maven/maven-get-oracle-drivers.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-layout: default
-title: Docs | Maven Get Oracle Drivers
-subnav: subnav_maven.md
----
-
-# How to Get Oracle Drivers using Maven
-Liquibase and Maven require the use of drivers to read your database. This topic walks you through the process of getting Oracle drivers while using Maven.
-
-## Step 1: Add a Dependency
-Add a dependency to the `` section of the Maven `pom.xml`, in your Maven project directory as follows:
-
-{% highlight xml %}
-
-
- com.oracle.jdbc
- ojdbc8
- 19.3.0.0
-
-
-{% endhighlight %}
-
-
-## Step 2: Login to Oracle
-Navigate to [https://www.oracle.com/webapps/maven/register/license.html](https://www.oracle.com/webapps/maven/register/license.html) and log in. If you do not have an account, please create one at this time.
-
-## Step 3: Include the Repository
-Update the `settings.xml` file located in your Maven project directory to include the [maven.oracle.com](https://www.oracle.com/webfolder/application/maven/index.html) repository:
-
-{% highlight xml %}
-
- maven.oracle.com
- oracle-maven-repo
- https://maven.oracle.com
- default
-
- true
- always
-
-
-{% endhighlight %}
-
-
-## Step 4: Include the Plugin
-Update your `settings.xml` file located in your Maven project directory to include the [maven.oracle.com](https://www.oracle.com/webfolder/application/maven/index.html) pluginRepository.
-
-{% highlight xml %}
-
- maven.oracle.com
- https://maven.oracle.com
-
-{% endhighlight %}
-
-
-## Step 5: Include the Server
-Update your `settings.xml` file in your Maven project directory to include the server for [maven.oracle.com](https://www.oracle.com/webfolder/application/maven/index.html).
-
-{% highlight xml %}
-
- maven.oracle.com
- YOUR ORACLE USERNAME
- YOUR ORACLE PASSWORD
-
-
- ANY
- ANY
- OAM 11g
-
-
-
-
-
- http.protocol.allow-circular-redirects
- %b,true
-
-
-
-
-
-
-{% endhighlight %}
-
-
-## Step 6: Create a settings-security.xml File
-Create a `settings-security.xml` file in your .m2 directory with your Oracle password in an encrypted format.
-> **Example:** {USER_HOME}/.m2/ directory.
-
-1. Encrypt your master password: `mvn -encrypt-master-password `
-2. Copy the encrypted password from the console.
-3. Paste the encrypted password into the `settings-security.xml` file located in your .m2 folder:
-
-{% highlight xml %}
-
- {YOUR ENCRYPTED MASTER PASSWORD}
-
-{% endhighlight %}
-
-
-## Step 7: Configure Maven
-Configure Maven with an HTTP Wagon compatible with [maven.oracle.com](https://www.oracle.com/webfolder/application/maven/index.html).
-
-- Download the HTTP Wagon jar from [Maven Central](http://central.maven.org/maven2/org/apache/maven/wagon/wagon-http/2.8/wagon-http-2.8-shaded.jar).
-- Copy the wagon-http jar into: `MAVEN_HOME/lib/ext/`
-
-To verify the configuration is correct, run `mvn compile`. If there are no errors stating that artifact com.oracle.jdbc cannot be
-found in [repo.maven.apache.org](http://repo.maven.apache.org/), then everything is configured correctly. If you are getting this error, make sure you have not omitted a step in these instructions.
diff --git a/documentation/maven/maven_changelogsync.md b/documentation/maven/maven_changelogsync.md
deleted file mode 100644
index 37a3fd810..000000000
--- a/documentation/maven/maven_changelogsync.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-layout: default
-title: Docs | Maven changelogsync
-subnav: subnav_maven.md
----
-# Maven changelogsync
-
-{% include_relative generated/changelogSync-mojo.html %}
diff --git a/documentation/maven/maven_changelogsyncsql.md b/documentation/maven/maven_changelogsyncsql.md
deleted file mode 100644
index 4736a5ea8..000000000
--- a/documentation/maven/maven_changelogsyncsql.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-layout: default
-title: Docs | Maven changelogsyncsql
-subnav: subnav_maven.md
----
-# Maven changelogsyncsql
-
-{% include_relative generated/changelogSyncSQL-mojo.html %}
diff --git a/documentation/maven/maven_clearchecksums.md b/documentation/maven/maven_clearchecksums.md
deleted file mode 100644
index cac08cbdb..000000000
--- a/documentation/maven/maven_clearchecksums.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-layout: default
-title: Docs | Maven clearchecksums
-subnav: subnav_maven.md
----
-# Maven clearchecksums
-
-{% include_relative generated/clearCheckSums-mojo.html %}
diff --git a/documentation/maven/maven_dbDoc.md b/documentation/maven/maven_dbDoc.md
deleted file mode 100644
index bc3ad3737..000000000
--- a/documentation/maven/maven_dbDoc.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven dbDoc
-subnav: subnav_maven.md
----
-# Maven dbDoc
-{% include_relative generated/dbDoc-mojo.html %}
diff --git a/documentation/maven/maven_diff.md b/documentation/maven/maven_diff.md
deleted file mode 100644
index 07f67c081..000000000
--- a/documentation/maven/maven_diff.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven diff
-subnav: subnav_maven.md
----
-# Maven diff
-{% include_relative generated/diff-mojo.html %}
diff --git a/documentation/maven/maven_dropall.md b/documentation/maven/maven_dropall.md
deleted file mode 100644
index 385c4371c..000000000
--- a/documentation/maven/maven_dropall.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven dropall
-subnav: subnav_maven.md
----
-# Maven dropall
-{% include_relative generated/dropAll-mojo.html %}
diff --git a/documentation/maven/maven_futurerollbacksql.md b/documentation/maven/maven_futurerollbacksql.md
deleted file mode 100644
index 047785617..000000000
--- a/documentation/maven/maven_futurerollbacksql.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven futureRollbackSQL
-subnav: subnav_maven.md
----
-# Maven futureRollbackSQL
-{% include_relative generated/futureRollbackSQL-mojo.html %}
diff --git a/documentation/maven/maven_generateChangeLog.md b/documentation/maven/maven_generateChangeLog.md
deleted file mode 100644
index 6e68cd514..000000000
--- a/documentation/maven/maven_generateChangeLog.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven generateChangeLog
-subnav: subnav_maven.md
----
-# Maven generateChangeLog
-{% include_relative generated/generateChangeLog-mojo.html %}
diff --git a/documentation/maven/maven_help.md b/documentation/maven/maven_help.md
deleted file mode 100644
index 5b6851094..000000000
--- a/documentation/maven/maven_help.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven help
-subnav: subnav_maven.md
----
-# Maven help
-{% include_relative generated/help-mojo.html %}
diff --git a/documentation/maven/maven_listlocks.md b/documentation/maven/maven_listlocks.md
deleted file mode 100644
index c912548e2..000000000
--- a/documentation/maven/maven_listlocks.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven listlocks
-subnav: subnav_maven.md
----
-# Maven listlocks
-{% include_relative generated/listLocks-mojo.html %}
diff --git a/documentation/maven/maven_migrate.md b/documentation/maven/maven_migrate.md
deleted file mode 100644
index 3c0fa1ae1..000000000
--- a/documentation/maven/maven_migrate.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven migrate
-subnav: subnav_maven.md
----
-# Maven migrate
-{% include_relative generated/migrate-mojo.html %}
diff --git a/documentation/maven/maven_migratesql.md b/documentation/maven/maven_migratesql.md
deleted file mode 100644
index b0acecfe1..000000000
--- a/documentation/maven/maven_migratesql.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven migratesql
-subnav: subnav_maven.md
----
-# Maven migratesql
-{% include_relative generated/migrateSQL-mojo.html %}
diff --git a/documentation/maven/maven_releaselocks.md b/documentation/maven/maven_releaselocks.md
deleted file mode 100644
index ddca3ea39..000000000
--- a/documentation/maven/maven_releaselocks.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-layout: default
-title: Docs | Maven releaselocks
-subnav: subnav_maven.md
-
----
-# Maven releaselocks
-{% include_relative generated/releaseLocks-mojo.html %}
diff --git a/documentation/maven/maven_rollback.md b/documentation/maven/maven_rollback.md
deleted file mode 100644
index 663ce4e8c..000000000
--- a/documentation/maven/maven_rollback.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: default
-title: Docs | Maven rollback
-subnav: subnav_maven.md
----
-# Maven Rollback
-
-> *Note* that there are [differences in how rollback works with Maven vs. how it works from the CLI](/documentation/maven/maven_rollback.html#differences-in-controlling-rollback-behavior)
-
-{% include_relative generated/rollback-mojo.html %}
-
-
-## Differences in Controlling Rollback Behavior
-
-Behavior | CLI Command | Maven
- ------ | ------ | ------
-rollback by count | rollbackCount 3 | rollback goal, liquibase.rollbackCount=3 property
-rollback by tag | rollback | rollback goal, liquibase.rollbackTag and liquibase.tag properties
-rollback to date | rollbackToDate | rollback goal, liquibase.rollbackDate property
-
diff --git a/documentation/maven/maven_rollbacksql.md b/documentation/maven/maven_rollbacksql.md
deleted file mode 100644
index cde38a2c1..000000000
--- a/documentation/maven/maven_rollbacksql.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven rollbacksql
-subnav: subnav_maven.md
----
-# Maven rollbacksql
-{% include_relative generated/rollbackSQL-mojo.html %}
diff --git a/documentation/maven/maven_status.md b/documentation/maven/maven_status.md
deleted file mode 100644
index 35c11d1a3..000000000
--- a/documentation/maven/maven_status.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven status
-subnav: subnav_maven.md
----
-# Maven status
-{% include_relative generated/status-mojo.html %}
diff --git a/documentation/maven/maven_tag.md b/documentation/maven/maven_tag.md
deleted file mode 100644
index 0e03d751f..000000000
--- a/documentation/maven/maven_tag.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven tag
-subnav: subnav_maven.md
----
-# Maven tag
-{% include_relative generated/tag-mojo.html %}
diff --git a/documentation/maven/maven_update.md b/documentation/maven/maven_update.md
deleted file mode 100644
index 984b56ed7..000000000
--- a/documentation/maven/maven_update.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven update
-subnav: subnav_maven.md
----
-# Maven update
-{% include_relative generated/update-mojo.html %}
diff --git a/documentation/maven/maven_updatesql.md b/documentation/maven/maven_updatesql.md
deleted file mode 100644
index 2aaaa3bd8..000000000
--- a/documentation/maven/maven_updatesql.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven updatesql
-subnav: subnav_maven.md
----
-# Maven updatesql
-{% include_relative generated/updateSQL-mojo.html %}
diff --git a/documentation/maven/maven_updatetestingrollback.md b/documentation/maven/maven_updatetestingrollback.md
deleted file mode 100644
index 1f399113d..000000000
--- a/documentation/maven/maven_updatetestingrollback.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: default
-title: Docs | Maven updatetestingrollback
-subnav: subnav_maven.md
----
-# Maven updatetestingrollback
-{% include_relative generated/updateTestingRollback-mojo.html %}
diff --git a/documentation/modify_sql.md b/documentation/modify_sql.md
deleted file mode 100644
index e64ded5ed..000000000
--- a/documentation/modify_sql.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-layout: default
-title: Docs | Modify SQL
----
-
-# Modifying Generated SQL #
-
-Although Liquibase supports most standard SQL statements with its change tags, there are times when the generated SQL needs to be slightly different for your particular needs. Examples include changing datatypes or adding additional vendor-specific clauses such as "ENGINE INNODB" to CREATE TABLE statements. **Since 1.9**
-
-## Sample ##
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-## Available Attributes ##
-
-
-
Attribute
Description
-
dbms
The type of a database which that changeSet is to be used for. When the migration step is running, it checks the database type against this
- attribute. Valid database type names are listed on the supported databases page. It is possible to list multiple databases separated by commas.
- You can also specify that a changeset is NOT applicable to a particular database type by prefixing with !. The keywords all and none are
- also available.
-
context
List of contexts in which to run the sql modification. If not specified, is applied in all contexts Since 2.0
-
applyToRollback
Should the sql modification be applied to rollback statements? Default='false' Since 2.0
-
-
-## Available Sub-Tags ##
-
-### prepend ###
-Adds SQL to the beginning of the statement.
-
-#### Available Attributes ####
-
-
Attribute
Description
-
value
Text to add to beginning of statement
-
-
-### append ###
-Adds SQL to the end of the statement.
-
-#### Available Attributes ####
-
-
Attribute
Description
-
value
Text to add to end of statement
-
-
-### replace ###
-Replaces all instances of the text specified.
-
-#### Available Attributes ####
-
-
Attribute
Description
-
replace
Text to replace
-
with
Text to replace with
-
-
-### regExpReplace ###
-Replaces all instances of the regular expression specified.
-
-#### Available Attributes ####
-
-
Attribute
Description
-
replace
Regular expression specifying text to replace
-
with
Text to replace with
-
diff --git a/documentation/multiple-sql-migration.md b/documentation/multiple-sql-migration.md
deleted file mode 100644
index 4b47acec4..000000000
--- a/documentation/multiple-sql-migration.md
+++ /dev/null
@@ -1,104 +0,0 @@
----
-layout: default
-title: Docs | Migrations with Multiple SQL Files
----
-# Database Migrations with Multiple SQL Files
-
-## Step 1: Create an SQL Folder
-To complete a migration, you must create an SQL folder in your Liquibase project folder. The SQL folder is where you will place all your your SQL scripts that Liquibase uses to track, version, and deploy changes to your database.
-
-## Step 2: Create or Generate a Changelog
-To use SQL script files, you must also have a [database changelog](/documentation/databasechangelog.html) file. While the SQL scripts define all of your database changes, Liquibase still requires the use of a changelog to tell it where your scripts are located. While you can use XML, JSON, YAML, or formatted SQL when creating a changelog, you must create an XML changelog to use multiple SQL Scripts.
-
-**Creating Changelog Files Manually**
-1. Create a file in your Liquibase project directory called `myChangeLog.xml`.
-2. For this example, enter the following information into the `myChangeLog.xml` file.
-
-{% highlight xml %}
-
-
-
-
-
-{% endhighlight %}
-
-When you have completed your work, save your file.
-
-**Generating Changelog Files**
-
-If you have an existing database, you can generate a changelog file that reflects the current state of your database.
-For more information on how to generate a changelog, visit the [Liquibase Commands: generateChangelog](/documentation/generating_changelogs.html) topic, and read the article about [Adding Liquibase on an Existing Project](/documentation/existing_project.html).
-
-## Step 3: Configure your Changelog
-To run SQL scripts, you must tell Liquibase where your SQL scripts are located. To configure your changelog, use the `includeAll` tag to point Liquibase to the correct folder.
-
-{% highlight xml %}
-
-
-
-
-
-
-{% endhighlight %}
-
-## Step 4: Add an SQL Script to the SQL Folder
-To add SQL scripts to your SQL folder:
-1. In your SQL folder, create a `.sql` file.
-2. For this example, enter the following information:
-
-{% highlight sql %}
-
-create table PERSON (
- ID int not null,
- FNAME varchar(100) not null
-);
-
-{% endhighlight %}
-
-When you have completed your work, save your file.
-
-## Step 5: Deploy your Script
-Once you have created and configured your changelog, and have also added your SQL scripts, you are ready to deploy.
-
-**To Deploy your Script**
-1. Open your command prompt or terminal.
-2. Run one of the following commands:
- - **Linux/Unix/Mac:** `LB_HOME/liquibase update`
- - **Windows:** `LB_HOME\liquibase.bat update`
-
-> **Note:** In place of `LB_HOME`, use the folder name where you extracted Liquibase.
-
-Your database should now contain a table called **PERSON**.
-
-## Step: Check your Database
-To check your database:
-1. Open your command prompt or terminal.
-2. Navigate to the folder where you placed your driver jar.
-3. Run: `java -jar (driver-version.jar)`
-
->**Note:** Where (driver-version.jar) is listed, enter your driver name and version number.
-
-**Example** `java -jar h2-1.4.199.jar`
-
-If you used a `liquibase.properties` file, enter the JDBC URL, User Name, and Password information. Notice that two tables were created:
-- DATABASECHANGELOG
-- DATABASECHANGELOGLOCK
-
-The DATABASECHANGELOG table contains a list of all the changes that have been run against the database. The DATABASECHANGELOGLOCK table is used to make sure two machines don't attempt to modify the database at the same time.
-
-View the [DATABASECHANGELOG Table](/documentation/databasechangelog_table.html) and [DATABASECHANGELOGLOCK Table](/documentation/databasechangeloglock_table.html) topics for more information.
-
-### Summary
-In this tutorial we covered:
-- Creating/Generating Changelogs
-- Adding Changesets to your Changelog
-- Running your Changelog
-- Checking your Database
\ No newline at end of file
diff --git a/documentation/offline.md b/documentation/offline.md
deleted file mode 100644
index 2dc5416be..000000000
--- a/documentation/offline.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-layout: default
-title: Docs | Offline Database Support
----
-
-# Offline Database Support #
-
-If you cannot run Liquibase directly against a database, there are two major options to ensure your database is kept up to date
-
-## updateSql
-
-The most common way to manage "offline" databases is to use the updateSql functionality.
-
-The updateSql command reads a database's DATABASECHANGELOG table and outputs the SQL that would run as part of the upgrade.
-This SQL includes inserts into the DATABASECHANGELOG table and can be ran against any database to both upgrade it and keep its history correct.
-
-It is important that the database you generate the SQL from is the same as the database(s) you plan to run the SQL against.
-
-Unless you have preconditions in your changelog file, the updateSql process only reads the DATABASECHANGELOG table to determine what changeSets to run.
-Therefore if, for example, you have a production database that you cannot run Liquibase against directly and it may be different than your test databases,
-you can copy/restore just the DATABASECHANGELOG table from the production database into a database you can run updateSql against. Then run the generated SQL against the actual production database.
-
-## Offline Database
-
-_Since 3.1.0_
-
-If your environment does not lend itself to using updateSql with test and backup databases, you can run Liquibase using an "offline" database.
-
-Running in offline mode only supports "updateSql", "rollbackSQL", "tag", and "tagExists". It does not support direct update, diff, or preconditions as there is nothing to actually update or state to check.
-
-An offline database is "connected" to using a url syntax of `offline:DATABASE_TYPE?param1=value1&aparam2=value2`.
-
-### Available parameters:
-
-| **changeLogFile** | Specify the file acting as the DATABASECHANGELOG table. Defaults to "databasechangelog.csv" in the working directory. |
-| **version** | Specify the database version to ensure generated SQL matches target database version. Example: 5.4.2 or 12.1.0.3 |
-| **productName** | Specify "product name" seen by the JDBC driver. |
-| **catalog** | Specify the connection catalog |
-| **caseSensitive** | Specify if the database is case sensitive or not |
-| **outputLiquibaseSql** | If set to "true", output from updateSQL will include create/insert statements for the DatabaseChangeLog table. Defaults to "false" |
-
-### Examples:
-
-- `offline:oracle`
-- `offline:mssql?changeLogFile=/src/changelog.csv`
-- `offline:mysql?version=5.4.21&changeLogFile=/src/changelog.csv`
diff --git a/documentation/other_formats.md b/documentation/other_formats.md
deleted file mode 100644
index 509d9ca68..000000000
--- a/documentation/other_formats.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-layout: default
-title: Docs | Other Formats
----
-
-# Other Changelog formats
-
-Beyond the built in [XML](xml_format.html), [YAML](yaml_format.html), [JSON](json_format.html) and [SQL](sql_format.html) changelog formats,
-the Liquibase extension system allows you to create changelog files in whatever format you like.
-
-Additional community-managed formats include:
-- [Groovy Liquibase](https://github.com/liquibase/liquibase-groovy-dsl)
-- [Clojure Liquibase Wrapper](https://github.com/kumarshantanu/clj-liquibase)
diff --git a/documentation/preconditions.md b/documentation/preconditions.md
deleted file mode 100644
index 773621eb3..000000000
--- a/documentation/preconditions.md
+++ /dev/null
@@ -1,323 +0,0 @@
----
-layout: default
-title: Docs | Preconditions
----
-# Preconditions
-
-Preconditions can be attached to [change logs](databasechangelog.html) or [changesets](changeset.html) to control the execution of an update based on the state of the database.
-
-There are several reasons to use preconditions, including:
-
-* Document what assumptions the writers of the *changelog* had when creating it.
-* Enforce that those assumptions are not violated by users running the *changelog*.
-* Perform data checks before performing an unrecoverable change such as [drop_Table](changes/drop_table.html)
-* Control what *changeSets* are run and not run based on the state of the database.
-
-If desired, a precondition can be the only tag in a ``.
-
-Preconditions at the *changelog* level apply to **all** *changeSets*, not just those listed in the current *changelog* or its child *changelogs*.
-
-## Sample With Preconditions
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
- select count(*) from oldtable
-
- Comments should go after preCondition. If they are before then liquibase usually gives error.
-
-
-
-{% endhighlight %}
-
-The above *changelog* will only run if the database executed against is Oracle and the database user executing the script is "SYSTEM". It will also only run the [drop_Table](changes/drop_table.html) command if there are no values in the "oldtable".
-
-## Handling Failures and Errors
-
-Liquibase distinguishes between precondition "failures" (check failed) and "errors" (exception thrown in execution of check) and the reaction to both can be controlled via the "onFail" and "onError" attributes on the `` tag. **Since 1.8**
-
-### Available attributes
-
-
-
Attribute
Description
-
onFail
What to do when preconditions fail (see below).
-
onError
What to do when preconditions error (see below).
-
onSqlOutput
What to do in updateSQL mode (see below). Since 1.9.5
-
onFailMessage
Custom message to output when preconditions fail. Since 2.0
-
onErrorMessage
Custom message to output when preconditions fail. Since 2.0
-
-
-### Possible onFail/onError values
-
-
-
Value
Description
-
HALT
Immediately halt the execution of the entire change log. [DEFAULT]
-
CONTINUE
Skip over the *changeSet*. Execution of the change set will be attempted again on the next update. Continue with the *changelog*.
-
MARK_RAN
Skip over the change set, but mark it as executed. Continue with the change log.
-
WARN
Output a warning and continue executing the *changeSet*/*changelog* as normal.
-
-
-Outside a *changeSet* (e.g. at the beginning of the change log), only HALT and WARN are possible values.
-
-### Possible onSqlOutput values
-
-
-
Value
Description
-
TEST
Run the changeSet in updateSQL mode.
-
FAIL
Fail the preCondition in updateSQL mode.
-
IGNORE
Ignore the preCondition in updateSQL mode (default).
-
-
-## AND/OR/NOT Logic
-
-Conditional logic can be applied to preconditions using nestable ``, `` and `` tags. **If no conditional tags are specified, it defaults to AND**.
-
-Examples:
-
-{% highlight xml %}
-
-
-
-
-{% endhighlight %}
-
-Will check that the update is running on Oracle AND with the SYSTEM user, but will only generate a warning if the precondition fails.
-
-{% highlight xml %}
-
-
-
-
-{% endhighlight %}
-
-Will require running on Oracle AND MySQL, which will always be false, unless a huge and unexpected merger takes place.
-
-{% highlight xml %}
-
-
-
-
-
-
-{% endhighlight %}
-
-Will require running on Oracle OR MySQL which makes more sense than the above example.
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-Will require running as SYSTEM if executing against an Oracle database or running as SA if running against a MS-SQL database.
-
-
-## Available Preconditions
-
-
-### <dbms>
-
-Passes if the database executed against matches the type specified.
-
-#### Available Attributes
-
-
Attribute
Description
-
type
Type of database expected. Multiple dbms values can be specified using comma separated values. required
-
-
-### <runningAs>
-
-Passes if the database user executed under matches the username specified.
-
-#### Available Attributes
-
-
Attribute
Description
-
username
Database user script is expected to run as. required
-
-
-### <changeSetExecuted>
-
-Passes if the specified change set has already been executed. **Since 1.8**
-
-#### Available Attributes
-
-
Attribute
Description
-
id
Change set "id". required
-
author
Change set "author". required
-
changeLogFile
File name (including classpath relative path) of change set. required
-
-
-### <columnExists>
-
-Passes if the specified column exists in the database. **Since 1.8**
-
-#### Available Attributes
-
-
Attribute
Description
-
schemaName
Name of the table's schema. required
-
tableName
Name of the column's table. required
-
columnName
Name of column. required
-
-
-### <tableExists>
-
-Passes if the specified table exists in the database. **Since 1.8**
-
-#### Available Attributes
-
-
-
Attribute
Description
-
schemaName
Name of the table's schema. required*
-
tableName
Name of the table. required
-
-
-### <viewExists>
-
-Passes if the specified view exists in the database. **Since 1.8**
-
-#### Available Attributes
-
-
-
Attribute
Description
-
schemaName
Name of the view's schema. required
-
viewName
Name of the view. required
-
-
-### <foreignKeyConstraintExists>
-
-Passes if the specified foreign key exists in the database. **Since 1.8**
-
-#### Available Attributes
-
-
-
Attribute
Description
-
schemaName
Name of the foreign key's schema. required
-
foreignKeyName
Name of the foreign key. required
-
-
-### <indexExists>
-
-Passes if the specified index exists in the database. **Since 1.8**
-
-#### Available Attributes
-
-
-
Attribute
Description
-
schemaName
Name of the index's schema. required
-
indexName
Name of the index. required
-
-
-### <sequenceExists>
-
-Passes if the specified sequence exists in the database. **Since 1.8**
-
-#### Available Attributes
-
-
-
Attribute
Description
-
schemaName
Name of the sequences's schema. required
-
sequenceName
Name of the sequence. required
-
-
-### <primaryKeyExists>
-
-Passes if the specified primary key exists in the database. **Since 1.8**
-
-#### Available Attributes
-
-
-
Attribute
Description
-
schemaName
Name of the primary key's schema.
-
primaryKeyName
Name of the primary key. tableName OR primaryKeyName required
-
tableName
Name of the table containing primary key. tableName OR primaryKeyName requiredSince 1.9
-
-
-### <sqlCheck>
-
-Executes an SQL string and checks the returned value. The SQL must return a single row with a single value. To check numbers of rows, use the "count" SQL function. To check for ranges of values, perform the check in the SQL and return a value that can be easily compared against.
-
-{% highlight xml %}
-SELECT COUNT(1) FROM pg_tables WHERE TABLENAME = 'myRequiredTable'
-{% endhighlight %}
-
-#### Available Attributes
-
-
-
Attribute
Description
-
expectedResult
Value to compare the SQL result to. required
-
-
-### <changeLogPropertyDefined>
-
-Checks whether given [changelog parameter](changelog_parameters.html#property) is present. If a value is also given, it only fails, if the value is not the same as given. **Since 2.0**
-
-{% highlight xml %}
-
-
-{% endhighlight %}
-
-#### Available Attributes
-
-
-
Attribute
Description
-
property
Name of the property to check for. required
-
value
Required value for given property.
-
-
-### <customPrecondition>
-
-Custom preconditions can be created by creating a class that implements the [liquibase.precondition.CustomPrecondition](/javadoc/liquibase/precondition/CustomPrecondition.html) interface. Parameters on custom classes are set through reflection based on the <param> sub-tags. Parameters are passed as strings to the custom precondition.
-
-{% highlight xml %}
-
-
-
-
-{% endhighlight %}
-
-#### Available Attributes
-
-
-
Attribute
Description
-
className
Name of custom precondition class. required
-
-
-#### Available Sub-Tags
-
-
-
Attribute
Description
-
param
Parameter to pass to the custom precondition.
-
-
-##### Available "param" sub-tag Attributes
-
-
-
Attribute
Description
-
name
Name of the parameter to set. required
-
value
String value to set parameter to. required
-
-
-## Implementation Notes
-
-Preconditions are checked at the beginning of the execution of a particular *changelog*. If you use the "include" tag and only have preconditions on the child *changelog*, those preconditions will not be checked until the migrator reaches that file. This behavior may change in future releases, so don't rely on this behavior.
diff --git a/documentation/rollback.md b/documentation/rollback.md
deleted file mode 100644
index 8baf2f0f8..000000000
--- a/documentation/rollback.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-layout: default
-title: Docs | Rollback
----
-
-# Rolling Back ChangeSets #
-
-Liquibase allows you to undo changes you have made to your database, either automatically or via custom rollback SQL. Rollback support is available in [command_line](command_line.html), [Ant](ant/index.html), and [Maven](maven/index.html).
-
-
-## How Rollback SQL is controlled ##
-
-Many refactorings such as "create table", "rename column", and "add column" can automatically create rollback statements. If your change log contains only statements that fit into this category, your rollback commands will be generated automatically.
-
-Other refactorings such as "drop table" and "insert data" have no corresponding rollback commands that can be automatically generated. In these cases, and cases where you want to override the default generated rollback commands, you can specify the rollback commands via the tag within the changeSet tag. If you do not want anything done to undo a change in rollback mode, use an empty tag.
-
-
-## Rollback Tag Available Attributes ##
-
-
-
Attribute
Description
-
nested tags
Standard Liquibase change tags to generate rollback statements
-
tag text
SQL to run to rollback this change. The text in the element is treated as a sql change with `stripComments` set to `true`,
-`splitStatements` set to `true` and `endDelimiter` set to `;`.
-
changeSetId
Id of changeset to rerun in order to rollback this change. Example: for rolling back a dropTable change, reference the changeSet that created the table.
-
changeSetAuthor
Author of changeset to rerun in order to rollback this change
-
changeSetPath
Normalized name of the file containing the changeset to rerun in order to rollback this
- changeSet. If not defined, the actual file is used.
-
-
-## Samples ##
-
-Many change tags do not need a rollback tag. They can be generated from the update statement.
-{% highlight xml %}
-
-
-
-
-
-{% endhighlight %}
-
-Standard change tags can be used in a `` tag
-{% highlight xml %}
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-Multiple statements can be included in one `` tag. Multiple rollback tags can be specified in one changeSet.
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
- drop table multiRollback1;
- drop table multiRollback2;
-
- drop table multiRollback3
-
-{% endhighlight %}
-
-A rollback tag can reference the changeSet that originally created a statement.
-{% highlight xml %}
-
-
-
-
-{% endhighlight %}
-
-Rollback tags can be empty if no rollback is possible/needed
-{% highlight xml %}
-
- insert into multiRollback3 (id) values (1)
-
-
-{% endhighlight %}
-
-## "Roll Back To" Modes ##
-
-You can specify what changes to rollback in three ways:
-
-
-
-### Tag ###
-
-Specifying a tag to rollback to will roll back all change-sets that were executed against the target database after the given tag was applied. See the [command line](command_line.html) documentation for how to tag your database.
-
-### Number of Change Sets ###
-
-You can specify the number of change-sets to rollback.
-
-### Date ###
-
-You can specify the date to roll back to.
-
-## Roll back Execution Modes ##
-
-Liquibase has three modes for managing rollbacks:
-
-### Execute Rollback Directly ###
-
-The rollback commands can be executed directly against the target database. If any changes cannot be rolled back, you will be notified and none of the changes will roll back.
-
-### Generating a Rollback Script ###
-
-Rather than actually updating the database, the SQL required to roll back the database can be generated. This is useful if you want to preview what rollback commands will be executed before they are actually run.
-
-### Generating a "Future Rollback" Script ###
-
-This mode is designed to allow you to generate a rollback script at the same time you generate your migration script. It allows you to take an updated application and generate both the SQL to update the database to the new version as well as the SQL to bring that new version back to the current version if needed. This functionality is very useful when a DBA wants to control SQL going into the database, as well as for applications that require rollback documentation for internal and/or ["SOX-compliant"](http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act) processes. You do not need to specify a rollback date, tag, or count in this mode.
diff --git a/documentation/running.md b/documentation/running.md
deleted file mode 100644
index 642c429c2..000000000
--- a/documentation/running.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-layout: default
-title: Docs | Running Liquibase
----
-
-# Running Liquibase #
-
-Liquibase can be ran either on demand or through automated processes.
-
-Liquibase ships with the following execution methods:
-
-## On Demand
-
-- Command Line
-- Ant
-- Maven
-
-## Automated
-
-- Servlet Listener
-- Spring Listener
-- JEE CDI Listener
-
-## Java APIs
-
-Liquibase can easily be embedded and executed through its Java APIs. For more information, see the Javadoc
-
-## Learn More
-
-Read our article on [How to Run Liquibase](https://download.liquibase.org/how-to-run-liquibase/) for more information on each of the methods above, why some users choose one method over another, and how to mix and match methods.
-
-
diff --git a/documentation/sdk/index.md b/documentation/sdk/index.md
deleted file mode 100644
index b80127883..000000000
--- a/documentation/sdk/index.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-layout: default
-title: Docs | SDK Home
----
-
-# Liquibase SDK
-
-### Purpose and Installation
-
-The purpose of the Liquibase SDK is facilitate development and testing of the Liquibase codebase and Liquibase extensions.
-The Liquibase SDK ships with the standard command line Liquibase installation which can be downloaded from [the Liquibase download page](http://download.liquibase.org).
-
-After unzipping liquibase-bin.zip or liquibase-bin.tar.gz you will find an "sdk" sub directory which contains everything related to the SDK.
-
-__Liquibase SDK is available in Liquibase 3.2.0+__
-
-### SDK Components
-
-* [__Javadoc__](/javadoc) The Liquibase core library API documentation is included in the LIQUIBASE_HOME/sdk/javadoc directory for easy offline reference.
-* [__Workspace__](workspace.html) To make testing easier, a pre-configured "workspace" directory is included with sample changelog files.
diff --git a/documentation/sdk/workspace.md b/documentation/sdk/workspace.md
deleted file mode 100644
index d5175364e..000000000
--- a/documentation/sdk/workspace.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-layout: default
-title: Docs | Workspace
----
-
-# Liquibase SDK Workspace
-
-The Liquibase SDK ships with a LIQUIBASE_HOME/sdk/workspace directory that is pre-configured as an easy starting point for testing Liquibase and Liquibase extensions.
-
-Normal usage of the workspace directory is to change to the workspace directory, then run `..\..\liquibase ARGS` and `..\liquibase-sdk ARGS` commands.
-
-__Liquibase SDK is available in Liquibase 3.2.0+__
-
-## Standard Workspace Contents
-
-### liquibase.properties
-
-The workspace directory ships with liquibase.h2.properties, liquibase.hsql.properties and liquibase.derby.properties files in the workspace directory which can be used for testing
-embedded databases. All three are configured to use database files in LIQUIBASE_HOME/tmp/DB_NAME.
-
-
-### changelog
-
-LIQUIBASE_HOME/sdk/changelog contains a starting `com/example/changelog.xml` file that can be used as a starting point for testing.
-
-
-The com/example/changelog.xml uses a variety of features including:
-
-* multiple authors
-* runAlways
-* dbms filtering
-* include
-* includeAll
-* relativeToChangelogFile
-* formatted SQL changelog format
-* YAML changelog format
-* rollback logic
-
-The created database structure includes:
-
-* A debug_info table for easy message logging
-* An employee table with an address table that references it
-* A simple shopping cart structure with item, account and cart_item tables
-* A simple newspaper structure with article and page tables
-
-## Tips
-
-* Zip or tar the the workspace directory for future reference and recovery
-* Add the workspace directory to your IDE project for easy access
-* Use the standard changelog structure as a starting point for reproducing and submitting Liquibase bugs
\ No newline at end of file
diff --git a/documentation/servlet_listener.md b/documentation/servlet_listener.md
deleted file mode 100644
index 313dfedb2..000000000
--- a/documentation/servlet_listener.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-layout: default
-title: Docs | Servlet listener
----
-
-# Servlet Listener #
-
-Liquibase can be run via a servlet listener. This allows you to have your database be updated automatically whenever the site is deployed. Since Liquibase uses distributed locking, this method will work just fine even if you have a cluster of application servers.
-
-To configure the servlet listener, simply add liquibase.jar to your WEB-INF/lib directory and the following to your web.xml file:
-
-{% highlight xml %}
-
- liquibase.changelog
- com/example/db.changelog.xml
-
-
-
- liquibase.datasource
- java:comp/env/jdbc/default
-
-
-
- liquibase.host.includes
- production1.example.com, production2.example.com
-
-
-
- liquibase.onerror.fail
- true
-
-
-
- liquibase.contexts
- production
-
-
-
- liquibase.integration.servlet.LiquibaseServletListener
-
-{% endhighlight %}
-
-
-**If using Liquibase 1.9.x**
-
-{% highlight xml %}
-
- LIQUIBASE_CHANGELOG
- com/example/db.changelog.xml
-
-
-
- LIQUIBASE_DATA_SOURCE
- java:comp/env/jdbc/default
-
-
-
- LIQUIBASE_HOST_EXCLUDES
- production1.example.com, production2.example.com
-
-
-
- LIQUIBASE_FAIL_ON_ERROR
- true
-
-
-
- LIQUIBASE_CONTEXTS
- production
-
-
-
- liquibase.servlet.LiquibaseServletListener
-
-{% endhighlight %}
-
-
-## Available context-parameters: ##
-
-
-
Parameter
1.9 version
Description
-
liquibase.changelog
LIQUIBASE_CHANGELOG
Specifies the changelog file to run required
-
liquibase.datasource
LIQUIBASE_DATA_SOURCE
JNDI datasource to use for running Liquibase. Note that the LIQUIBASE_DATA_SOURCE can be different than the data source the rest of your web app uses if that data source does not have sufficient privileges to create/alter tables etc. required
-
liquibase.host.excludes
LIQUIBASE_HOST_EXCLUDES
Specify host names on which you do NO want Liquibase to run. Specifying this parameter allows you to deploy the same WAR/EAR to multiple machines in different environments and not have Liquibase run on all of them.
-
liquibase.host.includes
LIQUIBASE_HOST_INCLUDES
Specify the ONLY host names on which want Liquibase to run. Specifying this parameter allows you to deploy the same WAR/EAR to multiple machines in different environments and not have Liquibase run on all of them.
-
liquibase.onerror.fail
LIQUIBASE_FAIL_ON_ERROR
Specify if an exception is thrown by Liquibase if an error occurs. Setting the value to "true" (default) will cause the exception to be thrown and keep the site from initializing properly. Setting the value to "false" will allow the site to deploy as normal, but the database will be in an undefined state.
-
liquibase.contexts
LIQUIBASE_CONTEXTS
A comma separated lists of the [contexts](contexts.html) to run in.
-
-
-If you want to control servers that run Liquibase but don't want to set the LIQUIBASE_HOST_EXCLUDES/LIQUIBASE_HOST_INCLUDES attributes, you can specify the "liquibase.should.run=\[true/false\]" system property.
diff --git a/documentation/snapshot.md b/documentation/snapshot.md
deleted file mode 100644
index bcc7e8abd..000000000
--- a/documentation/snapshot.md
+++ /dev/null
@@ -1,233 +0,0 @@
----
-layout: default
-title: Docs | snapshot Command
----
-
-# Liquibase Commands: snapshot
-The `snapshot` command has two modes. When run without options, it will gather the current state of the database and show a text-based version of the schema to STDOUT. When
-run with the `--snapshotFormat=JSON` option, creates a JSON file that represents the current state of your database. A snapshot is like a photograph of your database that
-can be used in the [diff](/documentation/diff.html) or [diffChangeLog](/documentation/diffChangeLog.html) commands.
-
-## Uses
-The `snapshot` command is typically used when you want to quickly compare changes in your database or keep a record of your current database state. Snapshots can also be used to compare:
-+ A previous database state to an online database
-+ A previous database state to another snapshot.
-> **Note:** Running a `diff` command using at least one *snapshot.json* file is faster than using a `diff` command with two online databases. However, keep in mind that a snapshot will no
-longer reflect the current state of the database if the database is changed with the `update` command or if it is changed manually.
-
-## Running the snapshot Command
-To take a snapshot of your database:
-1. Configure the *liquibase.properties* file to include your driver class path, URL, and user authentication information for your database.
-> **Note:** For information on how to configure your *liquibase.properties* file, view the [Creating & Configuring your *liquibase.properties* File](config_properties.html) topic in the knowledge base.
-2. Run the following command: `liquibase --outputFile=myschemaSnapshot.json snapshot --snapshotFormat=json`
-
-## Using the snapshot in the diff and diffChangeLog commands
-
-You can use the JSON format snapshot file in the diff and diffChangeLog commands. One typical workflow is:
-
- 1. Make sure your local environment is up-to-date by getting the latest changelog from source control.
- 2. Configure your liquibase.properties to point to a local development database and run `liquibase update` to ensure it has the latest schema.
- 3. Take a snapshot of the local development database with `liquibase --outputFile=before.json snapshot --snapshotFormat=json`
- 4. Make manual changes to the local development database as needed.
- 5. Add the manual changes to the changelog with `liquibase --referenceUrl=offline:mysql?snapshot=before.json diffChangeLog`
- 6. Review the changelog to ensure that it matches your expectations of the manual changes made.
- 7. Mark the manual changes as deployed in the local development database by running `liquibase changeLogSync`
- 8. Commit the changes to source control.
-
-The format for the database URL when using a snapshot is:
-
-{% highlight bash %}
-offline:?snapshot=
-{% endhighlight %}
-
-The `` in that URL should be the Type Name from [the list of supported databases](/databases.html), and the `` is a path relative to where the command is running.
-
-
-## Output
-
-myschemaSnapshot.json example
-
-{% highlight json %}
-{
- "snapshot": {
- "created": "2019-10-23T16:10:40.306",
- "database": {
- "productVersion": "Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production\nWith the Partitioning option",
- "shortName": "oracle",
- "majorVersion": "11",
- "minorVersion": "2",
- "user": "MYSCHEMA",
- "productName": "Oracle",
- "url": "jdbc:oracle:thin:@localhost:1521:ORCL"
- },
- "objects": {
- "com.datical.liquibase.ext.appdba.synonym.Synonym": [
- {
- "synonym": {
- "name": "PRIVATETABLESYN",
- "objectName": "PRIMARY_TABLE",
- "objectSchema": "liquibase.structure.core.Schema#b689101",
- "private": true,
- "schema": "liquibase.structure.core.Schema#b689101",
- "snapshotId": "b689152"
- }
- }]
- ,
- "liquibase.structure.core.Catalog": [
- {
- "catalog": {
- "default": true,
- "name": "MYSCHEMA",
- "snapshotId": "b689100"
- }
- }]
- ,
- "liquibase.structure.core.Column": [
- {
- "column": {
- "defaultValue": "1!{java.math.BigDecimal}",
- "name": "ACTIVE",
- "nullable": true,
- "order": "3!{java.lang.Integer}",
- "relation": "liquibase.structure.core.Table#b689129",
- "snapshotId": "b689133",
- "type": {
- "columnSize": "1!{java.lang.Integer}",
- "dataTypeId": "3!{java.lang.Integer}",
- "decimalDigits": "0!{java.lang.Integer}",
- "typeName": "NUMBER"
- }
- }
- }]
- ,
- "liquibase.structure.core.Index": [
- {
- "index": {
- "columns": [
- "liquibase.structure.core.Column#b689137"]
- ,
- "name": "PK_DATABASECHANGELOGLOCK",
- "snapshotId": "b689136",
- "table": "liquibase.structure.core.Table#b689135",
- "unique": true
- }
- }]
- ,
- "liquibase.structure.core.PrimaryKey": [
- {
- "primaryKey": {
- "backingIndex": "liquibase.structure.core.Index#b689136",
- "columns": [
- "liquibase.structure.core.Column#b689137"]
- ,
- "name": "PK_DATABASECHANGELOGLOCK",
- "snapshotId": "b689141",
- "table": "liquibase.structure.core.Table#b689135",
- "validate": true
- }
- }]
- ,
- "liquibase.structure.core.Schema": [
- {
- "schema": {
- "catalog": "liquibase.structure.core.Catalog#b689100",
- "default": true,
- "name": "MYSCHEMA",
- "snapshotId": "b689101"
- }
- }]
- ,
- "liquibase.structure.core.Table": [
- {
- "table": {
- "columns": [
- "liquibase.structure.core.Column#b689109",
- "liquibase.structure.core.Column#b689110",
- "liquibase.structure.core.Column#b689111",
- "liquibase.structure.core.Column#b689112",
- "liquibase.structure.core.Column#b689113",
- "liquibase.structure.core.Column#b689114",
- "liquibase.structure.core.Column#b689115",
- "liquibase.structure.core.Column#b689116",
- "liquibase.structure.core.Column#b689117",
- "liquibase.structure.core.Column#b689118",
- "liquibase.structure.core.Column#b689119",
- "liquibase.structure.core.Column#b689120",
- "liquibase.structure.core.Column#b689121",
- "liquibase.structure.core.Column#b689122"]
- ,
- "name": "DATABASECHANGELOG",
- "schema": "liquibase.structure.core.Schema#b689101",
- "snapshotId": "b689108"
- }
- }]
- ,
- "liquibase.structure.core.View": [
- {
- "view": {
- "columns": [
- "liquibase.structure.core.Column#b689149",
- "liquibase.structure.core.Column#b689150",
- "liquibase.structure.core.Column#b689151"]
- ,
- "definition": "SELECT \"ID\",\"NAME\",\"ACTIVE\"\n \nFROM \"MYSCHEMA\".\"DEPARTMENT\"",
- "editioning": false,
- "name": "VIEW1",
- "schema": "liquibase.structure.core.Schema#b689101",
- "snapshotId": "b689148"
- }
- }]
- ,
- "snapshotControl": {
- "snapshotControl": {
- "includedType": [
- "com.datical.liquibase.ext.appdba.synonym.Synonym",
- "com.datical.liquibase.ext.storedlogic.checkconstraint.CheckConstraint",
- "com.datical.liquibase.ext.storedlogic.databasepackage.DatabasePackage",
- "com.datical.liquibase.ext.storedlogic.databasepackage.DatabasePackageBody",
- "com.datical.liquibase.ext.storedlogic.function.Function",
- "com.datical.liquibase.ext.storedlogic.javalogic.JavaClass",
- "com.datical.liquibase.ext.storedlogic.javalogic.JavaSource",
- "com.datical.liquibase.ext.storedlogic.trigger.Trigger",
- "liquibase.structure.core.Catalog",
- "liquibase.structure.core.Column",
- "liquibase.structure.core.ForeignKey",
- "liquibase.structure.core.Index",
- "liquibase.structure.core.PrimaryKey",
- "liquibase.structure.core.Schema",
- "liquibase.structure.core.Sequence",
- "liquibase.structure.core.StoredProcedure",
- "liquibase.structure.core.Table",
- "liquibase.structure.core.UniqueConstraint",
- "liquibase.structure.core.View"]
-
- }
- }
- }
- }
-}
-{% endhighlight %}
-
-The `snapshot` command produces a JSON file that contains all your objects and places the file in the same directory as your *changelog*.
-
-Liquibase Community `snapshot` categories:
-+ Catalog
-+ Column
-+ Foreign Key
-+ Index
-+ Primary Key
-+ Schema
-+ Sequence
-+ Unique Constraints
-+ View
-
-
-Liquibase Pro `snapshot` categories:
-
-+ Package
-+ Package Body
-+ Procedures
-+ Function
-+ Trigger
-+ Synonyms
-+ Check Constraints
diff --git a/documentation/spring.md b/documentation/spring.md
deleted file mode 100644
index a4191b62a..000000000
--- a/documentation/spring.md
+++ /dev/null
@@ -1,230 +0,0 @@
----
-layout: default
-title: Docs | Using Liquibase with Spring Boot and Maven
----
-
-# Using Liquibase with Spring Boot and Maven Tutorial #
-
-When developing software, it is very common to create a database schema during production. Liquibase is a great migration tool that helps with creating the database schema, then running deployment and some testing to the database to ensure that the changes will work in production.
-The purpose of this tutorial is to demonstrate using Liquibase migration tool for a Java Spring Boot application with Maven.
-
-## Spring ##
-Liquibase can be run in a Spring environment by declaring a liquibase.spring.SpringLiquibase bean.
-
-### Example ###
-
-{% highlight xml %}
-
-
-
-
-
-
-
-{% endhighlight %}
-
-## Overview ##
-
-### What is Liquibase? ###
-Liquibase provides a great starting point for teams addressing the challenges that come with managing database schema changes.
-
-It has the ability to manage revisions of your database schema scripts. It works across various types of databases, and supports various file formats for defining the DB structure. Liquibase has the ability to roll changes back and forward from a specific point - saving you from the need to know what was the last change/script you ran on a specific DB instance.
-
-### What is Spring Boot? ###
-Spring Boot is an open source Java-based framework used to create a micro Service. It is developed by Pivotal Team and is used to build stand-alone and production-ready Spring applications.
-
-### What is Maven? ###
-Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.
-
-## Prerequisites ##
-* Install the latest version of Liquibase (These instructions include how to install Java.)
-* Download and install Maven.
-
-
-## Tutorial
-
-* Create a new project folder and name it **LiquibaseProj**.
-* In your LiquibaseProj folder, create a plain text document named **dbchangelog.xml**.
-Changelog files contain a sequence of changesets, each of which make small changes to the structure of your database. Instead of creating an empty changelog file in step 2, you can also use an existing database to generate a changelog. In this tutorial, you will manually add a single change. To add this change:
-* Open the dbchangelog.xml file and update the changelog file with the following code snippet:
-
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-
-* In your LiquibaseProj folder create a plain text document named **liquibase.properties**.
-* Edit the liquibase.properties file to add the following properties:
-{% highlight text %}
-
- changeLogFile: dbchangelog.xml
- url: jdbc:h2:mem:my_db;MODE=Mysql;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE;DATABASE_TO_UPPER=false;INIT=CREATE SCHEMA IF NOT EXISTS my_db\\;SET SCHEMA my_db
-
-{% endhighlight %}
-
-The changeLogFile property will point to the changelog we have created. Since the changelog is in the home directory, there is no need to specify a path to it. If the changelog is located somewhere else, then a relative path should be added.
-
-Windows example: `changeLogFile: ..\\\\changelogs\\dbchangelog.xml`
-
-Linux example: `..//changelogs/dbchangelog.xml`
-
-The url property is your Database url. In this example we are using an in-memory h2 database.
-If there is a user and password associated with the database, then the username and password properties should be added to the properties file as well.
-
-> Note: If you already have a Liquibase Pro key and want to apply it to
-> your project, add the following property to your liquibase.properties
-> file.
-liquibaseProLicenseKey: ``
-
-* Adding a changeset to the changelog – Change Sets are uniquely identified by “author” and ”id” attributes. Liquibase attempts to execute each changeset in a transaction that is committed at the end.
-
-In the dbchangelog.xml file line 9 to 20 add a new “department” create table change set as follows:
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-> Note: This create table change set is XML format. When the Liquibase update command is run, the changeset will be used to generate SQL
-> that is specific to the database platform. In this example, we are using an h2 in-memory database just for an example, and the SQL
-> generated would look like this:
-
-{% highlight sql %}
-CREATE TABLE "department"
-( "id" number(*,0),
- "name" VARCHAR2(50 BYTE),
- "active" NUMBER(1,0) DEFAULT 1
-);
-{% endhighlight %}
-
-
-* In your LiquibaseProj folder create a plain text document named **pom.xml**.
-* Open the pom.xml file and update it with the following code snippet:
-{% highlight xml %}
-
-
- 4.0.0
-
- org.springframework.boot
- spring-boot-starter-parent
- 2.1.9.RELEASE
-
-
- com.liquibase-support.app
- Liquibase-app-1
- 0.0.1-SNAPSHOT
- Liquibase-app
- Demo project for Spring Boot
-
- 8
- ${project.basedir}/liquibase.properties
-
-
-
- org.springframework.boot
- spring-boot-starter-web
-
-
- org.springframework.boot
- spring-boot-starter-test
- test
-
-
-
-
-
-
- org.liquibase
- liquibase-maven-plugin
- 3.8.0
-
- ${liquibase.propertyFile}
-
-
-
- com.h2database
- h2
- 1.4.200
-
-
- org.hibernate
- hibernate-core
- 5.4.6.Final
-
-
- javax.xml.bind
- jaxb-api
- 2.4.0-b180830.0359
-
-
-
-
- org.springframework.boot
- spring-boot-maven-plugin
-
-
-
-
-
-{% endhighlight %}
-
-
-* Download and unzip the src.zip to your LiquibaseProj directory.
-* In the src directory you will notice the path to your application code: src/main/java/com/application.java and the path to some junit tests: src/test/java/com/applicationTests.java.
-
-* The Spring Boot Maven plugin has many great features.
-1. It collects all the jar files in the classpath and builds a single "uber-jar". This makes it more convenient to execute your service.
-2. It searches for the "public static void main()" method to flag any classes with that method signature as a runnable class.
-
-* Open the command prompt or Bash. Navigate to the LiquibaseProj directory.
- Run the following command:
- ### mvn package
- This command will compile and test your Spring Boot Application code.
- ### mvn liquibase:update
-
-* In the console output you should notice the following SQL executions:
-For example:
-CREATE TABLE department (id INT NOT NULL, name VARCHAR(50) NOT NULL, active BOOLEAN DEFAULT TRUE, CONSTRAINT PK_DEPARTMENT PRIMARY KEY (id))
-Table department created.
-
-Also, you should see two more tables updated:
-* **DATABASECHANGELOG** tracking table – This table keeps a record of all the changesets that were deployed. This way, next time when you deploy again, the changesets in the changelog will be compared with the DATABASECHANGELOG tracking table and only the new changesets that were not found in the DATABASECHANGELOG will be deployed. You will notice that a new row was created in that table with the changeset information we have just deployed.
-For this example:
-
-|ID|AUTHOR |FILENAME |DATEEXECUTED|ORDEREXECUTED|EXECTYPE|MDSUM|...|
-|--|--|--|--|--|--|--|--|
-|1 |bob |dbchangelog.xml|`date&time`|1|EXECUTED|`checksumvalue`|...|
-
-* **DATABASECHANGELOGLOCK** – This table is used internally by Liquibase to manage access to the changelog table during deployment.
-
-## Conclusion ##
-Congratulations! You are now able to use Liquibase to manage both your Spring Boot application and its database with Maven.
-There is more information available on the [Liquibase Maven Plugin](maven/index.html) and its usage.
diff --git a/documentation/sql_format.md b/documentation/sql_format.md
deleted file mode 100644
index 6cdc9bada..000000000
--- a/documentation/sql_format.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-layout: default
-title: Docs | Formatted SQL Changelogs
----
-
-# Formatted SQL Changelogs #
-
-As of Liquibase 2.0, Liquibase includes support for "plain SQL" changelog files. These changelogs may be included from XML changelogs and may contain arbitrary SQL statements. The statements are converted to [custom_sql](changes/sql.html) refactorings.
-
-Formatted SQL files use comments to provide Liquibase with metadata. Each SQL file must begin with the following comment:
-
-{% highlight sql %}
---liquibase formatted sql
-{% endhighlight %}
-
-## Changesets ##
-
-Each changeset in a formatted SQL file begins with a comment of the form
-
-{% highlight sql %}
---changeset author:id attribute1:value1 attribute2:value2 [...]
-{% endhighlight %}
-
-The changeset comment is followed by one or more SQL statements, separated by
-semicolons (or the value of the `` attribute).
-
-### Available Changeset Attributes ##
-
-The following attributes may be provided on each changeset:
-
-
-
Attribute
Description
-
stripComments
Set to true to remove any comments in the SQL before executing, otherwise false. Defaults to true if not set
-
splitStatements
Set to false to not have liquibase split statements on ;'s and GO's. Defaults to true if not set
-
rollbackSplitStatements
Same as splitStatements but for rollback SQL
-
endDelimiter
Delimiter to apply to the end of the statement. Defaults to ";", may be set to "".
-
rollbackEndDelimiter
Same as endDelimiter but for rollback SQL
-
runAlways
Executes the change set on every run, even if it has been run before
-
runOnChange
Executes the change the first time it is seen and each time the change set has been changed
-
context
Executes the change if the particular context was passed at runtime. Any string can be used for the context name and they are checked case-insensitively.
-
logicalFilePath
Use to override the file name and path when creating the unique identifier of change sets. Required when moving or renaming change logs.
-
labels
Labels are general purpose way to categorize changeSets like contexts, but working in the opposite way. Instead of defining a set of contexts at runtime and then a match expression in the changeSet, you define a set of labels in the context and a match expression at runtime.
-
runInTransaction
Should the changeSet be ran as a single transaction (if possible)? Defaults to true. Warning: be careful with this attribute. If set to false and an error occurs part way through running a changeSet containing multiple statements, the Liquibase databasechangelog table will be left in an invalid state
-
failOnError
Should the migration fail if an error occurs while executing the changeSet?
-
dbms
The type of a database which that changeSet is to be used for. When the migration step is running, it checks the database type against this
- attribute. Valid database type names are listed on the supported databases page. It is possible to list multiple databases separated by commas.
- You can also specify that a changeset is NOT applicable to a particular database type by prefixing with !. The keywords all and none are
- also available.
-
logicalFilePath
Sets a logical file path in databasechangelog table instead of physical file location of sql where the liquibase executed.
-
-
-## Preconditions ##
-Preconditions can be specified for each changeset. Currently, only the SQL Check precondition is supported.
-
-{% highlight sql %}
---preconditions onFail:HALT onError:HALT
---precondition-sql-check expectedResult:0 SELECT COUNT(*) FROM my_table
-{% endhighlight %}
-
-## Rollback Actions ##
-
-Changesets may include statements to be applied when rolling back the changeset. Rollback statements are comments of the form
-{% highlight sql %}
---rollback SQL STATEMENT
-{% endhighlight %}
-
-## Comment ##
-A description of the change set. Future releases of Liquibase may be able to make use of comments to generate documentation.
-{% highlight sql %}
---comment: Some comment
-{% endhighlight %}
-
-## Valid CheckSum ##
-Checksum which are considered valid for this changeSet, regardless of what is stored in the database. Used primarily when you need to change a changeSet and don't want errors thrown on databases on which it has already run (not a recommended procedure).Since 3.5
-
-{% highlight sql %}
---validCheckSum: 3:098f6bcd4621d373cade4e832627b4f6
---validCheckSum: 7:ad0234829205b9033196ba818f7a872b
-{% endhighlight %}
-
-## Ignore lines ##
-Allow to ignore some lines. Useful when using same script with other SQL tool.
-Since 3.7
-
-Mark two lines to be ignored:
-{% highlight sql %}
---changeset author:id1
-CREATE OR REPLACE PACKAGE ...
---ignoreLines:2
-/
-show errors;
---changeset author:id2
-CREATE OR REPLACE PACKAGE BODY ...
-{% endhighlight %}
-
-Same effect using start-end syntax:
-{% highlight sql %}
---changeset author:id1
-CREATE OR REPLACE PACKAGE ...
---ignoreLines:start
-/
-show errors;
---ignoreLines:end
---changeset author:id2
-CREATE OR REPLACE PACKAGE BODY ...
-{% endhighlight %}
-
-## Sample Change Log ##
-
-{% highlight sql %}
---liquibase formatted sql
-
---changeset nvoxland:1
-create table test1 (
- id int primary key,
- name varchar(255)
-);
---rollback drop table test1;
-
---changeset nvoxland:2
-insert into test1 (id, name) values (1, ‘name 1′);
-insert into test1 (id, name) values (2, ‘name 2′);
-
---changeset nvoxland:3 dbms:oracle
-create sequence seq_test;
-{% endhighlight %}
diff --git a/documentation/sql_output.md b/documentation/sql_output.md
deleted file mode 100644
index 0602e29d8..000000000
--- a/documentation/sql_output.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-layout: default
-title: Docs | SQL Output
----
-
-# SQL Output #
-
-Depending on your development and release processes, you may not want Liquibase to directly update your database.
-Reasons for this may include a desire to tweak the resulting SQL, have the SQL approved by a DBA,
-or for [SOX compliance](/2007/07/sox-compliance-and-database-refactoring.html).
-
-For this reason, all [update](update.html) and [rollback](rollback.html) commands have an "sql output" mode which do not execute anything against the database but instead save the resulting SQL to standard out or a specified file.
diff --git a/documentation/trimming_changelogs.md b/documentation/trimming_changelogs.md
deleted file mode 100644
index 3240ae058..000000000
--- a/documentation/trimming_changelogs.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-layout: default
-title: Docs | Trimming ChangeLog
----
-
-# Trimming ChangeLog Files
-
-For people who have used Liquibase for a long time, a common question they have is how to clear out a changelog file that has gotten unwieldy.
-
-The standard process for using Liquibase is to append individual change sets to your changelog file for each database change you need to make. Over time those changes can build up to thousands of entries, many of which are now redundant (create a table and later drop it) or inefficient (create a table, then add columns individually vs. just creating the table with all the columns). What is the best way to simplify all that cruft that has built up?
-
-My first response is always "Do you really need to simplify it?" You built up that changelog over a long period of time and you have ran it and tested it countless times. Once you start messing with the changelog file you are introducing risk which has a cost of its own. Does whatever performance or file size concerns you have really outweigh the risk of messing with a script that you know works?
-
-If it is worth the risk, why is it work the risk? Sometimes the problem is that your changelog file has just gotten so large that your editor chokes on it, or you get too many merge conflicts. The best way to handle this is to simply break up your changelog file into multiple files. Instead of having a single changelog.xml file with everything in it, create a master.changelog.xml file which uses the tag to reference other changelog files.
-
-{% highlight xml %}
-
-
-
-
-{% endhighlight %}
-
-When you run `liquibase update` against the master.changelog.xml file, changeSets in com/example/news/news.changelog.xml will run and then the changeSets in com/example/directory/directory.changelog.xml will run. You can break up changeSets in whatever manner works best for you. Some break them up by feature, some break them up by release. Find what works best for you.
-
-Other times, the problem is that `liquibase update` is taking too long. Liquibase tries to be as efficient as possible when comparing the contents of the DATBASECHANGELOG table with the current changelog file and even if there are thousands of already ran changeSets, an "update" command should take just seconds to run. If you are finding that update is taking longer than it should, watch the Liquibase log to determine why. Perhaps there is an old runAlways="true" changeSet that no longer needs to run or there are preconditions which are no longer needed. Running Liquibase with --logLevel=INFO or even --logLevel=DEBUG can give additional output which can help you determine which changeSets are slow. Once you know what is slowing down your update, try to alter just those changeSets rather than throwing out the whole changelog and starting from scratch. You will still want to retest your changelog in-depth, but it is a far less risky change.
-
-For other people, they find that `liquibase update` works well for incremental updates, but creating a database from scratch takes far too long. Again I would ask "is that really a problem?" Are you re-creating databases often enough that the risk of a change to the creation script makes sense? If you are, your first step should be to look for problem changeSets as described above. Databases are fast, especially when they are empty. Even if you create a table only to drop it again that is usually just a few milliseconds of overhead and not worth optimizing. The biggest performance bottlenecks in creating a database are usually indexes, so start with them. If you are creating and updating indexes frequently in your creation process, you may be able to combine those changeSets into something more efficient.
-
-When you need to surgically alter your existing changeSets, remember how Liquibase works: each changeSet has an "id", an "author", and a file path which together uniquely identifies it. If the DATABASECHANGELOG table has an entry for that changeSet it will not run it. If it has an entry, it throws an error if the checksum for the changeSet in the file doesn't match what was stored on the last run.
-
-How you modify your existing changeSets will also depend on your environment and where in the changelog the problem changeSets are. If you are modifying changeSets that have been applied to all of your environments and are now only used on fresh database builds you can treat them differently than if they have been applied to some databases but not yet to others.
-
-To merge or modify existing changeSets you will be doing a combination of editing existing changeSets, removing old changeSets, and creating new ones.
-
-Removing unneeded changeSets is easy because Liquibase doesn't care about DATABASECHANGELOG rows with no corresponding changeSets. Just delete out of date changeSets and you are done. For example, if you have a changeSet that creates the table "cart" and then another that drops it, just remove both changeSets from the file. You must make sure, however, that there are no changeSets between the create and the delete that make use of that table or they will fail on a fresh database build. That is an example of how you are introducing risk when changing your changelog file.
-
-Suppose instead you have a "cart" table that is created in one changeSet, then a "promo_code" column is created in another and an "abandoned" flag is created in another.
-
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-One option would be to combine everything into a new changeSet using the existing id="1" and delete the other changeSets.
-
-{% highlight xml %}
-
-
- 7:f24b25ba0fea451728ffbade634f791d
-
-
-
-
-
-
-
-{% endhighlight%}
-
-This will work well if all existing databases have the cart table with the promo_code and abandoned columns already added. Running Liquibase against existing databases just sees that id="1" already ran and doesn't do anything new. Running Liquibase against a blank database will create the cart table with all the columns right away. Notice that we had to add the flag or existing databases will thow an error saying that id="1" has changed since it was run. Just use the checksum in the error message in the validCheckSum tag to mark that you know it changed and the new value is OK.
-
-If you have some databases where the promo_code and/or abandoned columns have not yet been added, update the original createTable as before, but use preconditions with onFail="MARK_RAN" to handle cases where the old changeSet ran while still not adding the columns again if the new changeSet ran.
-
-{% highlight xml %}
-
-
- 7:f24b25ba0fea451728ffbade634f791d
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-Now, on existing databases that have all 3 changeSets already ran, Liquibase will just continue on as before. For existing databases that have the old cart definition, it will see that the columns don't exist for id="2" and id="3" and execute then as usual. For blank databases, it will create the table with the promo_code and abandoned columns and then in id="2" and id="3" it will see that they are already there and mark that they have ran without re-adding the columns. A word of warning, however: using preconditions will add a performance overhead to your update executions and are ignored in updateSQL mode because Liquibase cannot know how applicable they are when changeSets have not actually executed. For that reason it is best to avoid them if possible, but definitely use them when needed. Preconditions also add complexity to your changelog which will require additional testing so keep that in mind when deciding whether to modify your changelog logic. Sometimes it is easiest and safest to wait until all your databases have the columns and then modify the changeSets to avoid the preconditions.
-
-The cart/promo_code/abandoned example shows some basic patterns you can use when modifying existing changeSets. Similar patters can be used to optimize whatever your bottlenecks are. Just remember when you change one changeSet, it can affect other changeSets below which may need to be modified as well. This can easily spider out of control so be mindful of what you are doing.
-
-If you end up finding that it will work best to completely restart your changelog, see "[Introducing Liquibase into an existing project](existing_project.html)" which describes how to add Liquibase to an existing project (even if that project was previously managed by Liquibase).
diff --git a/documentation/tutorials/apache-derby.md b/documentation/tutorials/apache-derby.md
deleted file mode 100644
index d2c2b0bee..000000000
--- a/documentation/tutorials/apache-derby.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-layout: default
-title: Docs | Apache derby
-subnav: subnav_tutorials.md
----
-
-# Apache Derby #
-
-Apache Derby can be downloaded here: [http://db.apache.org/derby/derby_downloads.html](http://db.apache.org/derby/derby_downloads.html)
-
-To use Derby with liquibase you will need the following information:
-
-**jars for the classpath:**
- * derby.jar
- * derbyclient.jar
-
-**jdbc driver name:**
- * org.apache.derby.jdbc.EmbeddedDriver
-
-**jdbc url:**
- * jdbc:derby:DATABASENAME
-
-Creating a database with Derby can be done with a tool called "ij" provided by Derby, as well as other ways.
-
-{% highlight console %}
-ij> CONNECT 'jdbc:derby:exampledb;create=true';
-{% endhighlight %}
-
-
-A run of liquibase with Derby, having both Derby jars and using the exampledb database folder in the current directory, could look like this:
-
-{% highlight console %}
-java -jar liquibase.jar
- --classpath=derby.jar:derbyclient.jar
- --driver=org.apache.derby.jdbc.EmbeddedDriver
- --url="jdbc:derby:exampledb"
- --changeLogFile=db-changelog.xml migrate
-{% endhighlight %}
-
-For further arguments you can pass to Derby, please have a look at Derby's documentation: [http://db.apache.org/derby/manuals/index.html](http://db.apache.org/derby/manuals/index.html)
diff --git a/documentation/tutorials/db2onz.md b/documentation/tutorials/db2onz.md
deleted file mode 100644
index eff90326f..000000000
--- a/documentation/tutorials/db2onz.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-layout: default
-title: Docs | Tutorials
-subnav: subnav_tutorials.md
----
-# DB2 on z/OS Tutorial
-
-
-### Step 1: Download and Extract Liquibase
-1. Download Liquibase. Visit the [download page](https://download.liquibase.org) to get the latest binary.
-2. After downloading the *.zip or *.tar.gz, extract the contents into a folder.
->**Note:** You may want to add this folder to your system PATH environment so that you can execute liquibase from any directory.
-
-For this tutorial, we will refer to that directory as `LB_HOME`, and when executing the liquibase shell script will use `LB_HOME/liquibase` or `LB_HOME\liquibase.bat` as the example command.
-
-### Step 2: Install Java
-1. Java is a required dependency. Install Java if it is not already installed.
->**Note:** You can download and use either the Oracle JDK or [OpenJDK](https://jdk.java.net/13/). Be sure to [configure](https://stackoverflow.com/questions/52511778/how-to-install-openjdk-11-on-windows) your PATH and environment variable properly.
-2. Validate that you have a working Java version. On the command line, execute: `java -version`
-
-Ensure that it runs successfully and displays your installed Java version.
-
-### Step 3: Download the DB2JCC Driver and License File
-The license JAR file is required when connecting to a mainframe DB2 database, which is not a free JAR file. You must purchase the DB2 Connect product. The license file is contained within the activation package for it.More information regarding the license file can be found [here](https://www.ibm.com/support/pages/location-db2jcclicensecisuzjar-file).
-1. Download the DB2JCC driver, which can be found [here](https://www.ibm.com/support/pages/db2-jdbc-driver-versions-and-downloads).
-2. Copy the `db2jcc.jar` and `db2jcc_license_cisuz.jar` files into the `lib` subdirectory of the `LB_HOME` directory where you extracted the Liquibase archive.
-
-### Step 4: Setup the liquibase.properties File
-While it is possible to pass all required parameters, such as the JDBC driver and database URL on the command line, it is much easier to configure a liquibase.properties file.
-
->**Pro Tip:** Create multiple liquibase.properties files for your DEV, QA, and PROD environments. You can pass the specific properties file as a liquibase command line argument.
-
-1. Create a new directory for your first liquibase project, and change into that directory. For this example, we named the directory db2_zos
-
-2. Create a plain text file named liquibase.properties in the project directory you just created and add the following content to the file.
-
-{% highlight text %}
-
-driver: com.ibm.db2.jcc.DB2Driver
-classpath: /lib/db2jcc.jar;>/lib/db2jcc_license_cisuz.jar>
-url: jdbc:db2://:/:retrieveMessagesFromServerOnGetMessage=true;emulateParameterMetaDataForZCalls=1;
-username:
-password:
-changeLogFile: db2zosChangeLog.xml
-
-{% endhighlight %}
-
->**Note:** Be sure to replace the with the actual values for your system.
-
-Ensure that you can execute liquibase. At the command prompt, run one of the following commands, depending on your platform:
-
-**Linux**
-
-`/liquibase --help`
-
-**Windows**
-
-`\liquibase.bat --help`
-
-You should now see some help output, and you are ready to begin using Liquibase. That is the completion of this Setup Tutorial. You are now ready to continue with deployment.
-
-
\ No newline at end of file
diff --git a/documentation/tutorials/h2.md b/documentation/tutorials/h2.md
deleted file mode 100644
index 2eead9367..000000000
--- a/documentation/tutorials/h2.md
+++ /dev/null
@@ -1,115 +0,0 @@
----
-layout: default
-title: H2 Tutorial | Liquibase Docs
-subnav: subnav_tutorials.md
----
-
-# **Creating New Liquibase Projects with H2 – Windows**
-The purpose of this document is to guide you through the process of creating a new Liquibase project with **H2** on a **Windows** machine. In this tutorial, you will generate an example project and follow the instructions to apply and learn concepts associated with creating new Liquibase Projects with H2.
-### Prerequisites
-* If you have not installed the latest version of Liquibase, navigate to [https://download.liquibase.org/download](https://download.liquibase.org/download) to install the software application.
-* Ensure the liquibase.bat file’s path is set to a location in the PATH System variable.
-* Navigate to [http://www.h2database.com/html/download.html](http://www.h2database.com/html/download.html) and download the jdbc driver jar file for H2 database.
-
-## Tutorial
-
-#### To create a Liquibase project with H2 database on your Windows machine, begin with the following steps:
-
-* Create a new project folder and name it **LiquibaseH2**.
-* Place the jdbc H2 jar driver file in the **LiquibaseH2** project directory.
-* In your LiquibaseH2 folder, Right-click then select New>Text Document to create an empty text file.
-* Rename the text file to **myChangeLog.xml**.
-Changelog files contain a sequence of changesets, each of which make small changes to the structure of your database. Instead of creating an empty changelog file in step 2, you can also use an existing database to generate a changelog. In this tutorial, you will manually add a single change. To add this change:
-* Open the myChangeLog.xml file and update the changelog file with the following code snippet:
-
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-
-* In your LiquibaseH2 folder Right-click and select New>Text Document to create a new text file.
-* Rename the text file to **liquibase.properties**.
-* Edit the liquibase.properties file to add the following properties:
-{% highlight properties %}
-
- changeLogFile: myChangeLog.xml
- url: jdbc:h2:file:./h2tutorial
- username: admin
- password: password
- classpath: h2-1.4.200.jar
-
-{% endhighlight %}
-
-
-> Note: In this properties file example, the driver jar file is "h2-1.4.200.jar" under the classpath: property. Please rename it to match the one that you have previously downloaded accordingly.
-
-* Adding a changeset to the changelog – Change Sets are uniquely identified by “author” and ”id” attributes. Liquibase attempts to execute each changeset in a transaction that is committed at the end.
-In the myChangeLog.xml file line 9 to 20 add a new “department” create table change set as follows:
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-> Note: This create table change set is XML format. The corresponding
-> SQL statement should look like the following:
-
-{% highlight sql %}
-CREATE TABLE "department"
- ("id" number(*,0),
- "name" VARCHAR2(50 BYTE),
- "active" NUMBER(1,0) DEFAULT 1
- );
-{% endhighlight %}
-
-* Open the command prompt. Navigate to the LiquibaseH2 directory.
- Run the following command:
-
- ### "liquibase update"
-* From a database UI Tool, for example: “DBeaver” check your database changes**.
-You should see a new “**department**” table added to the database. For example:
-
-{% highlight sql %}
-SELECT * FROM public.department;
-{% endhighlight %}
-
-
-|ID |NAME |ACTIVE |
-|--|--|--|
-|NULL |NULL |NULL|
-
-
-Also, you should see two more tables:
-* **DATABASECHANGELOG** tracking table – This table keeps a record of all the changesets that were deployed. This way, next time when you deploy again, the changesets in the changelog will be compared with the DATABASECHANGELOG tracking table and only the new changesets that were not found in the DATABASECHANGELOG will be deployed. You will notice that a new row was created in that table with the changeset information we have just deployed.
-For this example:
-
-|ID|AUTHOR |FILENAME |DATEEXECUTED|ORDEREXECUTED|EXECTYPE|MDSUM|...|
-|--|--|--|--|--|--|--|--|
-|1 |bob |dbchangelog.xml|`date&time`|1|EXECUTED|`checksumvalue`|...|
-
-* **DATABASECHANGELOGLOCK** – This table is used internally by Liquibase to manage access to the changelog table during deployment.
diff --git a/documentation/tutorials/index.md b/documentation/tutorials/index.md
deleted file mode 100644
index 6a749f9a2..000000000
--- a/documentation/tutorials/index.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-layout: default
-title: Docs | Database Tutorials
-subnav: subnav_tutorials.md
----
-# Liquibase Database Tutorials
-
-Welcome to the Liquibase Database Tutorials page! Learn more about using Liquibase with your favorite databases with
- our in-depth tutorials. You can also view our [Supported Databases]({{site.baseurl}}{% link databases.md %}) topic for more information.
-
-
diff --git a/documentation/tutorials/informix.md b/documentation/tutorials/informix.md
deleted file mode 100644
index 8bdf4db42..000000000
--- a/documentation/tutorials/informix.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: default
-title: Docs | Informix
-subnav: subnav_tutorials.md
----
-# Informix
-
-Running liquibase with the the JDBC driver located in the same directory as liquibase:
-
-{% highlight sh %}
-./liquibase
- --classpath=./ifxjdbc.jar
- --url="jdbc:informix-sqli://::informixserver=;
- database="
- generateChangeLog
-{% endhighlight %}
-
diff --git a/documentation/tutorials/mariadb.md b/documentation/tutorials/mariadb.md
deleted file mode 100644
index ff43241a7..000000000
--- a/documentation/tutorials/mariadb.md
+++ /dev/null
@@ -1,147 +0,0 @@
----
-layout: default
-title: Docs | MariaDB Tutorial
-subnav: subnav_tutorials.md
----
-# MariaDB Tutorial
-
-#### To test your connection, try running liquibase with the JDBC driver located in the same directory as liquibase:
-
-{% highlight sh %}
-
-liquibase
- --driver=org.mariadb.jdbc.Driver
- --classpath=./mariadb-java-client-1.4.6.jar
- --url="jdbc:mariadb://:/"
- --changeLogFile=db.changelog-1.0.xml
- --username=
- --password=
-generateChangeLog
-
-{% endhighlight %}
-
-
-## **Creating New Liquibase Projects with MariaDB AWS RDS – Windows**
-The purpose of this document is to guide you through the process of creating a new Liquibase project with **MariaDB AWS RDS** on a **Windows** machine. In this tutorial, you will generate an example project and follow the instructions to apply and learn concepts associated with creating new Liquibase Projects with MariaDB AWS RDS.
-### Prerequisites
-* If you have not installed the latest version of Liquibase, navigate to [https://download.liquibase.org/download](https://download.liquibase.org/download) to install the software application.
-* Ensure the liquibase.bat file’s path is set to a location in the PATH System variable.
-* Navigate to [https://mariadb.com/kb/en/library/about-mariadb-connector-j/ ](https://mariadb.com/kb/en/library/about-mariadb-connector-j/) and download the jdbc driver file for MariaDB.
-
-> **Note:** Place the jdbc jar driver file in a known directory so you can locate it easily.
-
->**Example:** C:\Users\Liquibase_Drivers\mariadb-java-client-2.4.4.jar
-
-## Tutorial
-
-#### To create a Liquibase project with MariaDB AWS RDS on your Windows machine, begin with the following steps:
-
-* Create a new project folder and name it **LiquibaseMariaDB_RDS**.
-* In your LiquibaseMariaDB_RDS folder, Right-click then select New>Text Document to create an empty text file.
-* Rename the text file to **dbchangelog.xml**.
-Changelog files contain a sequence of changesets, each of which make small changes to the structure of your database. Instead of creating an empty changelog file in step 2, you can also use an existing database to generate a changelog. In this tutorial, you will manually add a single change. To add this change:
-* Open the dbchangelog.xml file and update the changelog file with the following code snippet:
-
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-
-* In your LiquibaseMariaDB_RDS folder Right-click and select New>Text Document to create a new text file.
-* Rename the text file to **liquibase.properties**.
-* Edit the liquibase.properties file to add the following properties:
-{% highlight properties %}
-
- changeLogFile: C:\\Users\\Administrator\\LiquibaseMariaDB_RDS\\dbchangelog.xml
- url: jdbc:mariadb:// myrds.cz1j1vh9uvuo.us-east-1.rds.amazonaws.com:3306/mydatabase
- username: myrds
- password: password
- driver: org.mariadb.jdbc.Driver
- classpath: ../../Liquibase_Drivers/ mariadb-java-client-2.4.4.jar
-
-{% endhighlight %}
-Because you are creating this project on Windows OS, you must specify the path with double slashes in the changeLogFile property. You must also use a relative path from your project directory to the driver jdbc jar file location in the classpath property. Also, the url property should follow this template:
-##### url: jdbc:mariadb://{host}[:{port}]/[{databasename}]
-In our case, since we are using AWS RDS database instance, the host name should be copied from AWS website under your RDS --> Databases --> `` --> Connectivity & security --> Endpoint ``. This value should look similar to the value mentioned in the liquibase.properties example above.
-
-
-> Note: If you already have a Liquibase Pro key and want to apply it to
-> your project, add the following property to your liquibase.properties
-> file.
-{% highlight properties %}
-liquibaseProLicenseKey: ``
-{% endhighlight %}
-
-* Adding a changeset to the changelog – Change Sets are uniquely identified by “author” and ”id” attributes. Liquibase attempts to execute each changeset in a transaction that is committed at the end.
-In the dbchangelog.xml file line 9 to 20 add a new “department” create table change set as follows:
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-> Note: This create table change set is XML format. The corresponding
-> SQL statement should look like the following:
-
-{% highlight sql %}
-CREATE TABLE "department"
-("id" number(*,0),
- "name" VARCHAR2(50 BYTE),
- "active" NUMBER(1,0) DEFAULT 1
-);
-{% endhighlight %}
-
-* Open the command prompt. Navigate to the LiquibaseMariaDB_RDS directory.
- Run the following command:
-
-{% highlight sh %}
- liquibase update
-{% endhighlight %}
-
-* From a database UI Tool, check your database changes under “**mydatabase**”.
-You should see a new “**department**” table added to the database. For example:
-
-{% highlight sql %}
- SELECT * FROM my_schema.department;
-{% endhighlight %}
-
-
-|ID |NAME |ACTIVE |
-|--|--|--|
-|NULL |NULL |NULL|
-
-
-Also, you should see two more tables:
-* **DATABASECHANGELOG** tracking table – This table keeps a record of all the changesets that were deployed. This way, next time when you deploy again, the changesets in the changelog will be compared with the DATABASECHANGELOG tracking table and only the new changesets that were not found in the DATABASECHANGELOG will be deployed. You will notice that a new row was created in that table with the changeset information we have just deployed.
-For this example:
-
-|ID|AUTHOR |FILENAME |DATEEXECUTED|ORDEREXECUTED|EXECTYPE|MDSUM|...|
-|--|--|--|--|--|--|--|--|
-|1 |bob |dbchangelog.xml|`date&time`|1|EXECUTED|`checksumvalue`|...|
-
-* **DATABASECHANGELOGLOCK** – This table is used internally by Liquibase to manage access to the changelog table during deployment.
diff --git a/documentation/tutorials/mssql.md b/documentation/tutorials/mssql.md
deleted file mode 100644
index f67733d2c..000000000
--- a/documentation/tutorials/mssql.md
+++ /dev/null
@@ -1,146 +0,0 @@
----
-layout: default
-title: Docs | MSSQL Tutorial
-subnav: subnav_tutorials.md
----
-# MSSQL Tutorial
-
-#### To test your connection, try running liquibase with the JDBC driver located in the same directory as liquibase:
-
-{% highlight sh %}
-
-liquibase
---driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
---classpath=mssql-jdbc-7.4.1.jar
---url="jdbc:sqlserver://:1433;database=;
---changeLogFile=db.changelog-1.0.xml
---username=
---password=
-generateChangeLog
-
-{% endhighlight %}
-
-
-## **Creating New Liquibase Projects with MSSQL – Windows**
-The purpose of this document is to guide you through the process of creating a new Liquibase project with **MSSQL** on a **Windows** machine. In this tutorial, you will generate an example project and follow the instructions to apply and learn concepts associated with creating new Liquibase Projects with MSSQL.
-### Prerequisites
-* If you have not installed the latest version of Liquibase, navigate to [https://download.liquibase.org/download](https://download.liquibase.org/download) to install the software application.
-* Ensure the liquibase.bat file’s path is set to a location in the PATH System variable.
-* Navigate to [https://docs.microsoft.com/en-us/sql/connect/jdbc/download-microsoft-jdbc-driver-for-sql-server](https://docs.microsoft.com/en-us/sql/connect/jdbc/download-microsoft-jdbc-driver-for-sql-server) and download the jdbc driver file for SQL Server.
-
-> **Note:** Place the jdbc jar driver file in a known directory so you can locate it easily.
-
->**Example:** C:\Users\Liquibase_Drivers\mssql-jdbc-7.4.1.jar
-
-## Tutorial
-
-#### To create a Liquibase project with MSSQL on your Windows machine, begin with the following steps:
-
-* Create a new project folder and name it **LiquibaseMSSQL**.
-* In your LiquibaseMSSQL folder, Right-click then select New>Text Document to create an empty text file.
-* Rename the text file to **dbchangelog.xml**.
-Changelog files contain a sequence of changesets, each of which make small changes to the structure of your database. Instead of creating an empty changelog file in step 2, you can also use an existing database to generate a changelog. In this tutorial, you will manually add a single change. To add this change:
-* Open the dbchangelog.xml file and update the changelog file with the following code snippet:
-
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-
-* In your LiquibaseMSSQL folder Right-click and select New>Text Document to create a new text file.
-* Rename the text file to **liquibase.properties**.
-* Edit the liquibase.properties file to add the following properties:
-{% highlight properties %}
-
- changeLogFile: C:\\Users\\Administrator\\LiquibaseMSSQL\\dbchangelog.xml
- url: jdbc:sqlserver://localhost:1433;database=MYDATABASE;
- username: system
- password: password
- driver: com.microsoft.sqlserver.jdbc.SQLServerDriver
- classpath: ../../Liquibase_Drivers/mssql-jdbc-7.4.1.jar
-
-{% endhighlight %}
-Because you are creating this project on Windows OS, you must specify the path with double slashes in the changeLogFile property. You must also use a relative path from your project directory to the driver jdbc jar file location in the classpath property.
-
-> Note: If you already have a Liquibase Pro key and want to apply it to
-> your project, add the following property to your liquibase.properties
-> file.
-{% highlight properties %}
-liquibaseProLicenseKey: ``
-{% endhighlight %}
-
-* Adding a changeset to the changelog – Change Sets are uniquely identified by “author” and ”id” attributes. Liquibase attempts to execute each changeset in a transaction that is committed at the end.
-In the dbchangelog.xml file line 9 to 20 add a new “department” create table change set as follows:
-{% highlight xml %}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-{% endhighlight %}
-
-> Note: This create table change set is XML format. The corresponding
-> SQL statement should look like the following:
-
-{% highlight sql %}
-CREATE TABLE "department"
-("id" number(*,0),
- "name" VARCHAR2(50 BYTE),
- "active" NUMBER(1,0) DEFAULT 1
-);
-{% endhighlight %}
-
-* Open the command prompt. Navigate to the LiquibaseMSSQL directory.
- Run the following command:
-
-{% highlight sh %}
- liquibase update
-{% endhighlight %}
-
-* From a database UI Tool, for example: “MySQL Workbench” check your database changes under “**MYDATABASE**”.
-You should see a new “**department**” table added to the database. For example:
-
-{% highlight sql %}
- SELECT * FROM my_schema.department;
-{% endhighlight %}
-
-
-|ID |NAME |ACTIVE |
-|--|--|--|
-|NULL |NULL |NULL|
-
-
-Also, you should see two more tables:
-* **DATABASECHANGELOG** tracking table – This table keeps a record of all the changesets that were deployed. This way, next time when you deploy again,
-the changesets in the changelog will be compared with the DATABASECHANGELOG tracking table and only the new changesets that were not found in the
-DATABASECHANGELOG will be deployed. You will notice that a new row was created in that table with the changeset information we have just deployed.
-For this example:
-
-|ID|AUTHOR |FILENAME |DATEEXECUTED|ORDEREXECUTED|EXECTYPE|MDSUM|...|
-|--|--|--|--|--|--|--|--|
-|1 |bob |dbchangelog.xml|`date&time`|1|EXECUTED|`checksumvalue`|...|
-
-* **DATABASECHANGELOGLOCK** – This table is used internally by Liquibase to manage access to the changelog table during deployment.
diff --git a/documentation/tutorials/mysql.md b/documentation/tutorials/mysql.md
deleted file mode 100644
index 84823fae0..000000000
--- a/documentation/tutorials/mysql.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-layout: default
-title: Docs | MySQL Tutorial
-subnav: subnav_tutorials.md
----
-# MySQL Tutorial
-
-#### To test your connection, try running liquibase with the JDBC driver located in the same directory as liquibase:
-
-{% highlight sh %}
-
-liquibase
---driver=com.mysql.cj.jdbc.Driver
---classpath=mysql-connector-java-5.1.21-bin.jar
---url="jdbc:mysql://:/?autoReconnect=true&useSSL=FALSE|TRUE"
---changeLogFile=db.changelog-1.0.xml
---username=
---password=
-generateChangeLog
-
-{% endhighlight %}
-
-
-## **Creating New Liquibase Projects with MySQL – Windows**
-The purpose of this document is to guide you through the process of creating a new Liquibase project with **MySQL** on a **Windows** machine. In this tutorial, you will generate an example project and follow the instructions to apply and learn concepts associated with creating new Liquibase Projects with MySQL.
-### Prerequisites
-* If you have not installed the latest version of Liquibase, navigate to [https://download.liquibase.org/download](https://download.liquibase.org/download) to install the software application.
-* Ensure the liquibase.bat file’s path is set to a location in the PATH System variable.
-* Navigate to [https://dev.mysql.com/downloads/connector/j/](https://dev.mysql.com/downloads/connector/j/) and download the jdbc driver jar file for MySQL.
-
-> **Note:** Place the jdbc jar driver file in a known directory so you can locate it easily.
-
->**Example:** C:\Users\Liquibase_Drivers\mysql-connector-java-5.1.48.jar
-
-## Tutorial
-
-#### To create a Liquibase project with MySQL on your Windows machine, begin with the following steps:
-
-* Create a new project folder and name it **LiquibaseMySQL**.
-* In your LiquibaseMySQL folder, Right-click then select New>Text Document to create an empty text file.
-* Rename the text file to **dbchangelog.xml**.
-Changelog files contain a sequence of changesets, each of which make small changes to the structure of your database. Instead of creating an empty changelog file in step 2, you can also use an existing database to generate a changelog. In this tutorial, you will manually add a single change. To add this change:
-* Open the dbchangelog.xml file and update the changelog file with the following code snippet:
-
-
-{% highlight xml %}
-
-
-
-{% endhighlight %}
-
-
-* In your LiquibaseMySQL folder Right-click and select New>Text Document to create a new text file.
-* Rename the text file to **liquibase.properties**.
-* Edit the liquibase.properties file to add the following properties:
-{% highlight properties %}
-
- changeLogFile: C:\\Users\\Administrator\\LiquibaseMySQL\\dbchangelog.xml
- url: jdbc:mysql://localhost:3306/my_schema
- username: root
- password: password
- driver: org.gjt.mm.mysql.Driver
- classpath: ../../Liquibase_Drivers/mysql-connector-java-5.1.48.jar
-
-{% endhighlight %}
-Because you are creating this project on Windows OS, you must specify the path with double slashes in the changeLogFile property. You must also use a relative path from your project directory to the driver jdbc jar file location in the classpath property.
-
-> Note: If you already have a Liquibase Pro key and want to apply it to
-> your project, add the following property to your liquibase.properties
-> file.
-{% highlight properties %}
-liquibaseProLicenseKey: ``
-{% endhighlight %}
-
-* Adding a changeset to the changelog – Change Sets are uniquely identified by “author” and ”id” attributes. Liquibase attempts to execute each changeset in a transaction that is committed at the end.
-In the dbchangelog.xml file line 9 to 20 add a new “department” create table change set as follows:
-{% highlight xml %}
-
-
-
-
-
Congratulations to the winners of the 
-
-
-
-
-
-
-
-What I found most surprising was the length of time people have used Liquibase. For a project that was first released in 2006, I would have expected a larger contingent of people using it for longer than 4 years.
-It may be a result of newer users being most likely to visit liquibase.org and see the survey link, but it also a good sign for the project and the community that the user base is continuing to grow.
-Continued growth should be expected as well, since most people are using Liquibase daily or weekly as part of their normal development process, but many have so far only deployed to less than 1/4 of their projects.
-
-### Existing and Future Functionality
-
-
-
-
-
-
-
-One goal of the survey is to get an idea of what functionality people use and what could be improved upon. The general "how well does it meet your needs" peaks at a 4 and averages to 4, whereas the documentation averages only 3.3.
-Documentation is something that I've not spent nearly enough time on, and the results definitely confirms that. The "meets needs" response is OK, but could definitely be better.
-The extension question had 75% of people not writing extensions, so most people are making do with what ships with Liquibase vs. building their own functionality.
-
-The most helpful section of the survey was the free response questions since they gave people a chance to give specific details about what they liked and what they want improved.
-
-Some common themes in the answers included:
-
-##### What do you like most about Liquibase?
-
-- Use of non-sql XML and other formats to describe changes while still supporting SQL when needed
-- Database agnostic and independent
-- Simple/easy to use
-- Can set up automatic database updates that just work
-- Flexibility
-- Project reliability and community
-- Multiple options for defining changelogs
-
-##### What features do you wish Liquibase had?
-
-- Improved error messages and feedback
-- Improved groovy support
-- Ability to verify schemas
-- Support for more databases and database-specific functionality
-- NoSQL support
-- PostConditions
-- Looping construct
-- Consolidation of old changeSets
-- Static analysis/linting of changelogs
-
-##### What are your greatest pain points with Liquibase?
-
-- Migration of current workflow / adaption
-- Documentation
-- File encoding issues
-- Checksums
-- The logging system
-- Using Liquibase in OSGi
-- Functionality that may not work consistently across all database types
-- Lack of baselining support
-- Performance
-- Only Java-based
-- Mixed-case handling
-- Data type logic
-- Sometimes slow bugfixes and community responses
-- Required to use XML
-
-There was a lot of other great answers as well, both for specific features to add and more general suggestions.
-
-The areas for improvement generally lined up with what I was expecting, and are in the queue for upcoming releases which is always good.
-Issues with documentation appears not only as a called-out pain point, but also shows up as other issues (such as required use of XML) where existing functionality is not described well enough to be found.
-
-### Other demographics
-
-
-
-
-
-
-
-
-
-
-
-I always find real-life database usage interesting. For all the hype some databases get, Oracle squeaks out ahead of Postgresql and Mysql with a big drop-off to the rest.
-MS SqlServer is probably under-represented compared to the industry as a whole since Liquibase is Java-based, but I was also surprised at H2's popularity.
-I use H2 often while testing Liquibase because it is significantly faster for my tests than anything else, so it's good to see it is getting wider use.
-
-Not a big surprise that Java and Javascript dominated the technologies of Liquibase users, but I was surprised to see the other languages at nearly 10% usage each.
-
-I've always seen Liquibase as more of a developer-friendly tool, but was surprised to see just how dominant the use by developers are vs. other roles was. Perhaps it's all the XML that scares off everyone else...
-
-I was also surprised to see the agility responses not farther to the right given that Liquibase is an agile/refactoring type tool.
-
-### Comparisons to 2013 Results
-
-I purposefully kept the survey questions very close to the survey I did in 2013 to compare. Some highlights from comparing results:
-
-- Daily use increased from 43% to 53% while weekly use remained consistent
-- "How well does Liquibase meet your needs" increased from 3.6 to 4.0
-- "How helpful is the documentation" increased from 3.2 to 3.3
-- Database use was very consistent, other than an increase in DB2 use from 4% to 10%
-- Non-Java technology use increased from about 5% to about 10%
-- Agility increased from 3.4 to 3.5
-
-### Final Thoughts
-
-Thanks again to everyone who filled out the survey this year.
-
-While I get a good feel for how people are using Liquibase on an ongoing basis from questions asked, issues opened, and pull requests made, it is very helpful to have an alternate view of the project.
-There wasn't anything completely unexpected to alter the roadmap I have in my head, but it is also good to see that the changes I'm planning on making will address many of the pain points people are having.
-Plus, there are were several "that is a great idea, why didn't I think of that" suggestions which will be incorporated in future releases.
-
-My plan was to continue making incremental improvements to the 3.x codeline while concurrently working on a more major 4.0 release, and based on the survey results I think that plan continues to make sense.
-It appears that for the most part people are satisfied with Liquibase and it does most of what is needed. Consistency and reliability are important to them, and I don't want to throw major changes at them.
-However, while there are safe improvements such as performance and file encoding that can be made in 3.x, fully addressing things like checksums, mixed-case, and data types will require significant-enough changes that they are best wrapped up into a "you know there is going to require testing" 4.0 release.
-
-Documentation is also re-highlighted as something that needs more love as well. Liquibase is very flexible and has a lots of options, and not only does the raw features need to be better documented but how the various pieces can fit together to solve use cases and pain points needs to be better highlighted as well.
-
-If you have any question or suggestions please let me know or discuss it on the [forum](http://forum.liquibase.org/#Topic/49382000001371001).
\ No newline at end of file
diff --git a/_posts/2015-10-26-halloween-fun.md b/_posts/2015-10-26-halloween-fun.md
deleted file mode 100644
index d411ada5c..000000000
--- a/_posts/2015-10-26-halloween-fun.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Halloween Fun
----
-# Halloween Fun
-
-Halloween--the spookiest night of the year. Spookiest night for those who don't do production deployments anyway...
-
-So, for you sys admins, DBAs, and developers who know have stared down the terrors of a release night and fought the ghouls of last minute "shouldn't cause a problem" changes here are three games to make your Halloween party more fun.
-
-Each is formatted to fit standard paper, click on the images below for the full-size game.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-### Summing it up
-
-* Liquibase is used by companies of all sizes.
-* Most Liquibase users find the tool useful and use extensions to meet their needs.
-* Although most users find the documentation helpful, we’d love to see that number higher than 68%. We’ll look at improving the documentation and providing links in more helpful places in the near future.
-
-We also took the time to interview a handful of users to ask more in-depth questions to see what features they’re looking for. More on that soon.
-
-Thanks to all that participated in the survey and interviews! We look forward to making improvements and getting more feedback from the community.
diff --git a/_posts/2019-08-07-improving-community-support.md b/_posts/2019-08-07-improving-community-support.md
deleted file mode 100644
index c4f8ce1e2..000000000
--- a/_posts/2019-08-07-improving-community-support.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Improving Community Support
----
-# Improving Community Support
-
-It’s an exciting time for the Liquibase community. The latest release, 3.7, has over 350 commits from the community and from Datical.
-Datical has dedicated several engineers to the Liquibase open source project.
-Most recently, these efforts helped push the [Liquibase 3.7 release](/2019/07/liquibase-3-7-0-released.html) with several important new features including improved support for PostgreSQL, DB2, MariaDB, MS SqlServer, Ingres, and Firebase, and much more.
-
-### Liquibase Community Manager
-
-I’m very excited to share that we are looking to hire an [open source community manager](https://www.datical.com/company/careers/?gh_jid=1803669).
-This position will be vital to the community, helping to manage and improve the website and forum.
-They’ll also be responsible for responding to questions and comments as well as connecting with users to help improve everyone’s experience with Liquibase.
-If you’re passionate about building open source communities, [I encourage you to apply!](https://www.datical.com/company/careers/?gh_jid=1803669)
-
-> *NOTE* As of December 2019, this position has been filled. 
-
-Let’s say you want to roll back change ‘B’. Liquibase will only allow you to roll back change B by applying D’, C’ and B’ (basically rolling back D, C, and B) in order to “rollback change B”.
-
-
-
-If you attempt a rollback to a change and Liquibase does NOT have a valid rollback script for one of the changes in the sequence, the rollback operation will fail and nothing will be rolled back. Liquibase performs this check before it starts applying any rollbacks, so no harm is done, but nothing will happen. The state of your database will remain exactly the way it is.
-
-## Drop, rework, and deploy
-If you are working in a sandbox/developer environment, this option is for you. You can run a `liquibase dropAll` to drop everything from the database. (Do NOT use this in production!) Once you have a clean sandbox, you can edit any changesets you want to, and then run a `liquibase update` to deploy the changes you want. This is a great option for iterative development if (and only if) you have a sandbox environment where you have the luxury of dropping all objects.
-
-## Restore from backup
-This option only works if you have a backup and the ability to take the downtime to restore from a backup. It’s operating outside of Liquibase but is a path to resolution.
-
-## Do it live
-This option is also operating outside of Liquibase and when you do not have a backup or ability to restore from a backup.
-With this option, you connect to the database and beat it into the state you desire. It’s unequivocally the worst of all options. If you ever want these fixes to apply to other environments, it will definitely require some combination of using `validCheckSum`, `diffChangelog`, `changelogSync`, etc. depending on the specifics of what you actually do by hand. Undoubtedly, it is STRONGLY recommended you do NOT use this option, and that you talk your DBAs out of resorting to this option; bribe them if you must!
-
-## Summing it up
-Bad database changes happen. Depending on your situation and needs, there are several ways to handle a bad database change when you’re using Liquibase. We always recommend rolling forward whenever possible, but it’s good to know all of your options.
diff --git a/_posts/2019-12-16-Recent-Liquibase-Articles.md b/_posts/2019-12-16-Recent-Liquibase-Articles.md
deleted file mode 100644
index 9028e85e3..000000000
--- a/_posts/2019-12-16-Recent-Liquibase-Articles.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Recent Liquibase Articles, December 2019
-author: Steve Donie
----
-# Recent Liquibase Articles, December 2019
-
-Here are some recent mentions of Liquibase on other sites.
-
-* [Fear database changes? Get them under control with CI/CD](https://dev.to/heroku/fear-database-changes-get-them-under-control-with-ci-cd-44n1)
- 17 December 2019
-
- Why you should be including database concerns in your CI/CD process.
-
-* [Evolving Database using Spring Boot and Liquibase](https://www.roytuts.com/evolving-database-using-spring-boot-liquibase/)
- 16 Dec 2019
-
- Nice tutorial showing how to evolve your database over time, using YAML and SQL Configuration rather than XML. The author also has
- several other Liquibase related articles.
-
-* [Six Reasons You Should Try Liquibase for Your Next Project](https://medium.com/@texorcist/6-reasons-you-should-try-liquibase-for-your-next-project-47c5bf86ca9)
- 3 Dec 2019
-
- Datical's CTO Robert Reeves talks about why Liquibase is awesome.
-
-* [Liquibase and Titan: Open Source Database DevOps](https://medium.com/@texorcist/liquibase-and-titan-open-source-database-devops-bdeb19be4181)
- 27 September 2019
-
- Robert Reeves shows how Titan + Liquibase is a great model for working with databases in the development workflow. Titan is "docker for databases" and
- provides a great system for getting data into the hands of software developers.
-
-* [SpringBoot, Liquibase, and MariaDB](https://medium.com/@texorcist/6-reasons-you-should-try-liquibase-for-your-next-project-47c5bf86ca9)
- 24 September 2019
-
- Tutorial and Quick Start on using Liquibase with SpringBoot.
-
-
-* [Software Development Tools I Won't Do Without](https://medium.com/@stevedonie/software-development-tools-i-wont-do-without-58478d204d94)
- 9 November 2016
-
- An older article I wrote that describes why tools like Liquibase are as essential to the software development process as source control, testing,
- and continuous integration.
-
diff --git a/_posts/2019-12-17-liquibase-3-8-3-released.md b/_posts/2019-12-17-liquibase-3-8-3-released.md
deleted file mode 100644
index b4ae349e4..000000000
--- a/_posts/2019-12-17-liquibase-3-8-3-released.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.8.3 Released, Improves Maven Plugin Support
----
-# Liquibase 3.8.3 Release, Improves Maven Plugin Support
-
-Liquibase 3.8.3 is now available here through [Liquibase.org](https://download.liquibase.org/download-community/).
-The [3.8.3 release is also available on GitHub](https://github.com/liquibase/liquibase/releases/). Here's a closer look at what's included in the latest release.
-
-## Liquibase 3.8.3 Overview
-
-### Improved Support for Liquibase-Maven Plugin and Java 9+
-When you try to make a lot of improvements really fast, sometimes things can break. Thanks for letting us know that there was an issue with our last point release with Maven. We wanted to remedy this as quickly as possible. We're very happy to report with the release of Liquibase 3.8.3, users of both Liquibase Community and Liquibase Pro can enjoy improved Liquibase-Maven plugin experiences, especially when using Java 9+.
-
-### Bug Fixes
-The following bugs were fixed in version 3.8.3:
-- Liquibase-Maven plugin now works with Java 9+.
-- Expired license messages are now less annoying. (We made them less verbose and less excitable.)
-
-### Documentation
-All Liquibase users should also check out our continually improving documentation. For this release, there are two pages of special interest:
-- [Maven Liquibase Plugin](/documentation/maven/index.html)
-- [How to Get Oracle Drivers using Maven](/documentation/maven/maven-get-oracle-drivers.html)
-
-Full Liquibase documentation is available at [https://www.liquibase.org/documentation/index.html](/documentation/index.html).
-
-### Get Involved
-You can help make the Liquibase community better by contributing in the following ways:
-- Contribute code - [https://www.liquibase.org/development/contribute.html](https://www.liquibase.org/development/contribute.html)
-- Make documentation updates - [https://github.com/liquibase/liquibase.github.com/tree/master/documentation](https://github.com/liquibase/liquibase.github.com/tree/master/documentation)
-- Participate in our community survey and earn $10 for 10 minutes of your time - [https://www.surveymonkey.com/r/Liquibase-Survey-B](https://www.surveymonkey.com/r/Liquibase-Survey-B)
diff --git a/_posts/2019-12-23-liquibase-3-8-4-released.md b/_posts/2019-12-23-liquibase-3-8-4-released.md
deleted file mode 100644
index 16ac00310..000000000
--- a/_posts/2019-12-23-liquibase-3-8-4-released.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.8.4 Released, Corrects Spring Boot Error in Pro
----
-# Liquibase 3.8.4 Released, Corrects Spring Boot Error in Pro
-
-Liquibase 3.8.4 is now available here through [Liquibase.org](https://download.liquibase.org/download-community/).
-The [3.8.4 release is also available on GitHub](https://github.com/liquibase/liquibase/releases/). Here’s a closer look at what's included in the latest release.
-
-## Liquibase 3.8.4 Overview
-
-### Liquibase 3.8.4 Fix for Liquibase Pro Spring Boot Error
-Previously, running a Spring Boot application while using Liquibase 3.8.0+ in Java 9+ caused errors. With the release of Liquibase 3.8.4, users can now use primary workflows with embedded Liquibase cases.
-
-### Bug Fixes
-For both Liquibase Community and Liquibase Pro users, the following bugs were fixed in version 3.8.4:
-- Fixed a 'Class not Found' exception error when using Java +9.
-- Fixed a 'Cannot Use Default Schema Name' error when users diff against an SQL Server snapshot file.
-- Fixed an 'Unexpected type: java.util.Date' error when using a defaultValueDate attribute in a YAML changelog.
-- Improved datetime type handling in SQL Server. Liquibase now preserves types and prevents unexpected behaviors.
-
-### Documentation
-All Liquibase users should also check out our continually improving documentation. For this release, there are several pages with brand new video content! Check them out here:
-- [Creating & Configuring your liquibase.properties File](/documentation/config_properties.html)
-- [Generating SQL to Update Database Schemas](/documentation/generate-sql-update-schemas.html)
-- [Your First Migration with Liquibase Functions](/get_started/quickstart_lb.html)
-
-You can also see our growing library of videos and [subscribe to our YouTube channel](https://www.youtube.com/channel/UC5qMsRjObu685rTBq0PJX8w?).
-
-Full Liquibase documentation is available at [http://www.liquibase.org/documentation/index.html](/documentation/index.html).
diff --git a/_posts/2020-01-06-top-10-findings-liquibase-survey.md b/_posts/2020-01-06-top-10-findings-liquibase-survey.md
deleted file mode 100644
index 5662b85e8..000000000
--- a/_posts/2020-01-06-top-10-findings-liquibase-survey.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Top 10 Findings from Our Liquibase Community Survey
----
-# Top 10 Findings from Our 2019 Liquibase Community Survey
-
-First, a huge THANK YOU to everyone who participated in the Liquibase community survey. We had the best turnout ever and really appreciate all of the great input and feedback. We’ve already adjusted our road map to make sure we are building the features that you are asking for. The system works! Here are the top 10 findings from our survey.
-
-## 1 — Most Liquibase users are developers.
-We’ve learned that most people using Liquibase are coming from development and not from the database side. It’s interesting to understand our users’ backgrounds and what their focus is so that we can help more users get their jobs done easier and faster. Not only that, but it helps us figure out what type of information and analogies might be more useful in the documentation.
-
-
-
-## 2 — Liquibase is used by companies of all sizes.
-It’s fascinating to us to see how well Liquibase can work with different sized teams and for companies both big and small.
-
-
-
-Some of the respondents who opted to have a phone conversation with us have told us that Liquibase works great, but there are pain points around managing complex management tasks for really large deployments. We’re looking into options around what we can offer to help with the ecosystem around Liquibase.
-
-## 3 — Preferences for executing Liquibase are pretty clear.
-Understanding how the community executes Liquibase helps us understand where to invest our time. Maven and the command line are the favorites followed by Spring Boot, and custom shell scripts.
-
-
-
-## 4 — The most popular databases to use with Liquibase surprised us.
-There were some not officially supported (i.e., fully tested and vetted) databases that showed up high on our list and some supported ones that not many people use. It’s definitely time to make sure we’re officially supporting and thoroughly testing the databases the community works with most. We’d like to learn more from you about how you’re using Liquibase with databases like MySQL and MariaDB. Look for a conversation on this topic soon [on our subreddit](https://www.reddit.com/r/liquibase/).
-
-
-
-## 5 — Understanding your preference for writing change scripts.
-We asked the community for their preference for writing change scripts (1 being most preferred and 5 being least preferred). We hear you. Yes, many people like using XML, but many Liquibase users prefer SQL. What many people don't know is that you CAN use plain old SQL with Liquibase. We’ll be focusing on documenting the use of plain SQL better and also improving the overall experience for those that use SQL for change scripts.
-
-
-
-## 6 — Most of you are definitely interested in a centralized dashboard.
-We’ve added creating a dashboard that shows all Liquibase deployments in your organization to our road map! Exciting. We’ll be updating you on our progress here soon.
-
-
-
-## 7 — Most of you are using Jenkins for CI.
-There are a LOT of CI tools out there, but our survey shows most Liquibase users rely on Jenkins. We’d like to begin work on a Jenkins plugin for the community to make it even easier. If you’re interested in using an open source Jenkins plugin for Liquibase, let us know what you’d like to see as part of the plugin. Already make your own version? What should we be aware of? Let us know what you think and [join the discussion on our subreddit](https://www.reddit.com/r/liquibase/comments/ekxhld/jenkins_plugin_for_liquibase_weigh_in/).
-
-
-
-## 8 — We need to continue making our documentation better.
-We’ve made a ton of improvements recently and plan on making many more to our docs, add video tutorials, and make our getting started information more useful. If you haven't seen it lately, [check out the Documentation section](http://www.liquibase.org/documentation/index.html).
-
-Most of the other input we received was about adding or improving integrations and various features. More on that soon.
-
-## 9 — Features that you’d most like to see.
-Features that are highest in demand are around rolling back a specific change and an easier way to run platform-specific SQL. We’ve added these items to our road map and you’ll be seeing these become reality very soon!
-
-## 10 — Overall, you really like Liquibase.
-We received a lot of positive feedback from you. It’s exciting and fun to work on a project so many people love and rely on.
-
-Some positive pieces of feedback we wanted to share:
-
-“We use Liquibase in our CI/CD pipeline with Jenkins and it has worked well for us. We have been using SQL versus XML/JSON/YAML as it allows us to use Postgres BDR and PgLogical features that would otherwise have been unavailable.”
--- Andy K., Senior Software Architect at ACI Worldwide
-
-“I love using Liquibase. I don't want to think about doing database releases without it anymore.”
--- Anonymous
-
-“Liquibase is a great tool that changed the way I managed database changes.”
--- A.F., Development Manager
-
-“Fantastic tool.”
--- Anonymous
-
-Please keep sending feedback about things you wish were better, or submit a documentation pull request. There's a link at the bottom of every page of the site.
\ No newline at end of file
diff --git a/_posts/2020-01-09-liquibase-3.8.5-released.md b/_posts/2020-01-09-liquibase-3.8.5-released.md
deleted file mode 100644
index d931de4a3..000000000
--- a/_posts/2020-01-09-liquibase-3.8.5-released.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-layout: default
-subnav: subnav_blog.md
-title: Liquibase 3.8.5 Released, Many Bug Fixes
----
-# Liquibase 3.8.5 Released, Many Bug Fixes
-
-Liquibase 3.8.5 is now available here through [Liquibase.org](https://download.liquibase.org/download-community/).
-The [3.8.5 release is also available on GitHub](https://github.com/liquibase/liquibase/releases/). Here’s a closer look at what's included in the latest release.
-
-## Liquibase 3.8.5 Bug Fix Overview
-
-We've fixed a number of issues with this release.
-
-### Bug Fixes
-For both Liquibase Community and Liquibase Pro users, the following bugs were fixed in version 3.8.5:
-
-- Fixes issue in which Liquibase did not add `DESC` to an `id` column
-- CLI once again accepts `sqlFile`, `delimiter`, `rollbackScript`, and `outputSchemaAs` arguments
-- Fixes Stored Procedure whitespace impacting update calls
-- Fixes `generateChangelog` failure when there are missing NOT NULL constraints
-- Fixes `updateSQL`, which was not including schemaName for package bodies
-- Fixes bug in which Liquibase was not always capturing `create package body` while generating changeLog
-- Liquibase CLI now gives a more useful error message when an invalid character is passed to a command
-- Fixes an MSSQL issue, which threw an exception when doing diff/diffChangeLog between offline connections (such as when snapshotting json files)
-- Fixes an MSSQL issue, which incorrectly generated `datetime` data type column when using `diff` & `diffChangeLog` Liquibase Maven plugin fails while executing/using "diff" and "generateChangeLog" with PostgreSQL)
-
-## Community Engagement
-We recently shared a [blog about our top findings from our most recent Liquibase Community Survey](https://www.liquibase.org/2020/01/top-10-findings-liquibase-survey.html). Thank you to everyone who participated.
-
-Want to provide more feedback and input? Ready to learn what we're up to? We're having a virtual Liquibase Community Meetup on January 23 with Nathan (Liquibase Project Founder), Steve (Liquibase Community Manager), and Mario (Liquibase Product Manager). Join us. We're looking forward to meeting with you.
-
-### Example Workflow
-
-Starting state: there are 3 active branches: "master", "3.0.x", and "3.1.x". 3.0.3 and 3.1.2 are the most recent releases in the previous release families.
-
-Because 3.1 has been released, most development is occurring off the "master" branch. Features are developed in fork branches off "master" and when they are done, pull requests are created and accepted into master.
-
-If a bug is found that needs to be fixed in a 3.1, it is worked on in a branch off 3.1 and when it is done a pull request is created and accepted into the 3.1.x branch.
-
-When we are ready to have a 3.1.3 release, the 3.1.x branch is tagged as "3.1.3" and then merged into "master".
-
-When we are ready to release the code in "master" and a version number is decided on such as 3.2, a "3.2.x" branch is created for final testing and tagged as "3.2.0" at release time.
-
diff --git a/development/building.md b/development/building.md
deleted file mode 100644
index d4a8bcfe3..000000000
--- a/development/building.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-layout: default
-title: Docs | Building Liquibase
----
-
-# Building Liquibase
-
-Liquibase is built using Maven 3. There is a top-level Maven pom.xml file in the root directory which will build each of the sub-modules in turn.
-3rd party jar dependencies are configured within the Maven pom.xml files and are automatically downloaded as part of the build process.
-
-## Build Requirements
-
-* Java SE JDK 1.8 or higher installed
-* Maven 3.0 or higher
-* No OS requirements
-
-## Running Maven
-
-1. Download maven 3.0 or greater from [maven.apache.org](http://maven.apache.org)
-1. Unzip maven wherever you prefer
-1. `cd ROOT_LIQUIBASE_SOURCE_DIR`
-1. `/MAVEN_HOME/bin/mvn package`
-
-Build output goes to the "target" directory under each top level directory. The standard liquibase core jar file is in `ROOT_LIQUIBASE_SOURCE_DIR/liquibase-core/target/liquibase-VERSION.jar`
-
-**Note: If you prefer to build Liquibase without running the tests, run `/MAVEN_HOME/bin/mvn -DskipTests=true package`**
diff --git a/development/code_org.md b/development/code_org.md
deleted file mode 100644
index 10c3ad84a..000000000
--- a/development/code_org.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-layout: default
-title: Docs | Architecture
----
-
-# Liquibase Code Organization
-
-## Repository Structure
-
-All Liquibase code is accessible from [github.com/liquibase](http://github.com/liquibase).
-
-The [github.com/liquibase/liquibase](http://github.com/liquibase/liquibase) repository contains the core Liquibase library. This includes:
-
-* Code for supported Databases
-* Standard Change/Refactoring code
-* Code for running Liquibase through the command prompt, Ant, Maven, a servlet container, and Spring.
-* Code for parsing and writing XML, YAML, JSON, and SQL changelog formats
-
-From [github.com/liquibase](http://github.com/liquibase) you can also access the code for Liquibase-managed extensions such as [github.com/liquibase-mssql](http://github.com/liquibase/liquibase-mssql)
-
-### Liquibase Core vs. Liquibase Extensions
-
-Liquibase is designed to be a small core of functionality that will work in a standard way across all database types, but with the ability to extend, enhance and even replace that functionality as needed.
-More information about writing extensions can be found at the [extension portal](../extensions/index.html).
-
-We take advantage of that design even with our code by keeping database-specific functionality and non-common logic in extensions rather than continuing to add additional modes and flags to the base library.
-For example, there is not support for managing packages and triggers across all database types, but if we want to introduce that support for Oracle we can create a liquibase-oracle extension that supports that.
-Similarly, if want to provide a way to ignore all checksums, rather than build that potentially bad practice into the main codebase we will create an extension.
-
-There is a fine line sometimes between what should go in core and what should be an extension, and features do migrate in and out of core as well. If you have questions on where functionality is or should go,
-you can always [use the developer forums](../community/index.html).
-
-## Top level Directory Structure
-
-The main Liquibase repository contains 4 top level directories to divide the codebase
-
-1. **liquibase-core** contains all code for the standard Liquibase functionality
-1. **liquibase-integration-tests** contains only tests that actually run against databases.
-1. **liquibase-maven-plugin** contains code for Maven support.
-1. **liquibase-osgi** contains an osgi compatible BundleActivator for Liquibase
-
-## Project configurations(s)
-
-Liquibase uses Maven as its build system, with pom files corresponding to each of the top level directories, plus a "parent" pom in the root directory.
-Dependencies between top-level directories and 3rd party jar files can be found within the maven pom.xml files.
-
-For those using IntelliJ IDEA, there there is a project configuration in .idea directory format as part of the repository.
-The intellij config is built directly from the maven projects.
-
-For those using Eclipse, you can automatically create your project config from the Maven pom.xml files.
-
-## General Module Code Structure
-
-Each of the top-level directories/modules follows the standard maven source layout with a "src" dir containing both a "main" and a "test" directory.
-Within both main and test, there is a "java" directory which contains the java code and a "resources" directory for non-source code files.
-
-## Liquibase-Core Code Structure
-
-In the liquibase-core module, all code exists under the "liquibase" package.
-There is a second-level package for each of the major code units withing Liquibase such as "liquibase.change" and "liquibase.parser".
-
-Because most packages support extensions, you will normally find a \*Factory class which loads the available classes. Each package will normally have a "core" 3rd level package that contains the built-in standard functionality.
-Interfaces and other classes needed for given feature are generally within the second level package.
-
-For example:
-
-* The liquibase-core/src/main/java/liquibase/change directory contains all "change" related logic
-* liquibase/change contains ChangeFactory.java which will find all available Change implementations.
-* liquibase/change contains Change.java, AbstractChange.java, CheckSum.java and other classes used by core and extension Change classes.
-* There is a liquibase-core/src/main/java/liquibase/change/core directory which contains all the built-in Change implementations such as CreateTableChange.java and DropViewChange.java
-
-For more information, see the [javadoc](../javadoc/index.html) or [check out the code](http://github.com/liquibase/liquibase).
diff --git a/development/contribute.md b/development/contribute.md
deleted file mode 100644
index 83f3e801b..000000000
--- a/development/contribute.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-layout: default
-title: Docs | Contributing to Liquibase
----
-
-# Contributing to Liquibase #
-
-## Using GitHub ##
-
-Liquibase uses the typical GitHub pull request workflow. GitHub provides great documentation including [How to Fork a Repository](https://help.github.com/articles/fork-a-repo) and [Using Pull Requests](https://help.github.com/articles/using-pull-requests).
-
-The root Liquibase repository is at [http://github.com/liquibase/liquibase](http://github.com/liquibase/liquibase). To contribute fixes and features:
-
-1. Create a fork of the main repository using the "Fork" button in the GitHub web interface
-1. Clone your new repository to your computer
-1. Create a branch in your repository for the fix or feature you are going to contribute
-1. Code and test until done
-1. Using git, "push" your changes back up to your local GitHub repository
-1. Create a pull request in the GitHub web interface
-1. Participate in any discussion on the pull request
-
-## Git crash course ##
-
-If you have not used Git or GitHub before, there are many resources available including [Git - SVN Crash Cource](http://git.or.cz/course/svn.html) and the general [GitHub Help](http://help.github.com).
-
-If you would prefer to use subversion, GitHub [transparently supports SVN clients as well](https://github.com/blog/1178-collaborating-on-github-with-subversion)
-
-## Code Guidelines ##
-
-* The Liquibase project uses standard Java conventions
-* Curly braces go on the same line as the "if" statements
-* Git commit messages should include the Jira issue number, the issue summary, and a description of the how the change fixes the issue. For example "CORE-2822 YAML changelogs do not actually run included files. Finished implementation of the runIncludedChangeLog() method".
-* Prefer smaller more frequent commits over larger monolithic commits
-* Make sure your pull request target branch follows the [branching standards](branches.html).
-* Create a pull request per feature or bug. Don't combine multiple independent changes into a single pull request.
-* Include test cases for your features and bugs
diff --git a/development/index.md b/development/index.md
deleted file mode 100644
index 3175255a8..000000000
--- a/development/index.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-layout: default
-title: Docs | Liquibase Development
----
-
-# Liquibase Development
-
-## Source Code ##
-
-The core Liquibase source code is at [http://github.com/liquibase/liquibase](http://github.com/liquibase/liquibase).
-
-All standard extensions are a part of the [http://github.com/liquibase](http://github.com/liquibase).
-
-* [How to Contribute Code](contribute.html)
-* [Branch Structure](branches.html)
-* [Code Organization](code_org.html)
-* [Building Liquibase](building.html)
-* [Javadoc](../javadoc/index.html)
-
-## Extensions vs. Core
-
-Liquibase is designed to support adding, enhancing, and overriding standard functionality through our extension framework.
-Often times, the best way to add new functionality is to create a new extension or add to an existing one rather than modifying the base library.
-
-For more information on how to write extensions, see [the extension portal](../extensions/index.html).
-
-## Issue Tracking ##
-
-**Liquibase Core**
-
-Bugs and features for the core Liquibase project are managed at [http://liquibase.jira.com/browse/CORE](http://liquibase.jira.com/browse/CORE).
-
-For more information, see [Liquibase Jira Workflow](jira.html)
-
-**Extensions**
-
-Issue tracking for extensions are handled as they see fit.
-
-For more information, see the individual extension pages on the [the extension portal](../extensions/index.html).
\ No newline at end of file
diff --git a/development/jira.md b/development/jira.md
deleted file mode 100644
index 34188e155..000000000
--- a/development/jira.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-layout: default
-title: Docs | Using Jira
----
-
-# Using Jira
-
-The core Liquibase project uses [liquibase.jira.com](http://liquibase.jira.com/browse/CORE) as its bug and feature tracker.
-
-If you have a bug or feature that you are working on or would like to have worked on, it should have an issue logged.
-
-## Jira Fields
-
-We limited down the available fields in Jira to a small but generally required set. We use them as follows:
-
-**Title/Summary** is the one line description of the feature or bug.
-
-Choose a title that is descriptive and to the point, keeping in mind that it will appear in the Jira release notes and be used by others to know what is in a release.
-
-**Issue Type** contains just three options:
-1. "Bug" for things that cause errors or do not work as expected
-1. "Feature" for brand new features
-1. "Improvement" for new functionality on existing features
-
-**Priority** contains four options:
-1. "Blocker" for bugs and missing features that are stopping you from using Liquibase
-1. "Major" for bugs and missing features that interfere with your ability to use Liquibase, but you are able to work around the problem
-1. "Nice to Have" for bugs and missing features that would be nice to have fixed or changed, but do not interfere with your usage
-1. "Trivial" for bugs and missing features that are inconsequential.
-
-**Affects Version** should contain the version in which you saw the bug the most recent version if it is a feature request.
-
-**Fix Version** should be set to the version(s) in which the change is going to be made.
-Normally this will be the next upcoming version, but if the change needs to be backported to previous release families specify both the current next version and all backported versions.
-
-For example, if 3.1.3 is the version under development, but a bug needs to be fixed in the upcoming 3.0.4 version as well, set the Fix Version to "3.1.3, 3.0.4".
-
-This should not be set until it has been determined that the issue will be fixed in a given release, either because you or someone else is actually going to fix it in that time frame.
-
-**Environment** should describe your setup for a bug or the setup improved with a feature request. Include things like database type and version, operating system, and anything else that seems relevant to diagnosing and/or reproducing the issue.
-
-**Description** should include enough information that someone else could reproduce your bug or understand the feature you want added. At a minimum, include these three things:
-1. **What I did**
- - steps you took, files used, command executed, relevant environment information
-1. **What actually happened**
- - Describe what happened, any error messages, output files, etc.
-1. **What I expected to happen**
- - This is much better than just saying "It doesn't work".
-
-## Audiences ##
-
-There are many different usages and audiences of issues entered in Jira. Remember to keep these people in mind when creating and working with Jira issues:
-
-1. **People looking through the Jira backlog looking for something to fix** There are often lots of issues to chose from and if your issue is vague or incomplete
- there is a good chance it will be skipped over.
-1. **The person fixing the bug** Make sure you are putting yourself in their shoes and thinking through what they will need. If you have done some troubleshooting or
- debugging and have any information that will make their job easier, make sure to include it.
-1. **Others that are seeing a similar issue or want a similar feature** Describe your bug or feature well enough that somebody else running into it will find your
- issue rather than creating a duplicate or variation. Not only do duplicates lead to confusion for everyone, but we lose out on the chance to collaborate on a solution.
-1. **Readers of the release notes** For each release, a link to the generated Jira release notes is made available. Make sure your title makes obvious what was changed.
-
-## Jira Workflow ##
-
-Liquibase uses "Open", "In Progress" and "Awaiting Merge" and "Closed" issues. We don't differentiate between Open vs. Reopened or Closed vs. Resolved.
-
-All new issues will be created as "Open". When anyone begins working on an issue, they should assign it themselves and change the status to "In Progress". If it turns
-out that they will not actually resolve the issue, they will unassign it and set the status back to "Open".
-
-When the fix or feature is "done" and ready to bring into the main codebase, the issue moves to "Awaiting Merge". At that point, the developer should create a GitHub pull
-request and reference the pull request in the Jira comments.
-
-If the pull request is accepted, the issue will be changed to "closed". If the pull request is rejected, discussion will normally happen within the pull request interface
-until it is either accepted or given up on at which case the issue status will go back to "Open".
-
-See the [how to contribute](contribute.html) documentation for more information on pull requests.
-
-
-
diff --git a/documentation/ant/changelogsync_ant_task.md b/documentation/ant/changelogsync_ant_task.md
deleted file mode 100644
index 477c35c7d..000000000
--- a/documentation/ant/changelogsync_ant_task.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-layout: default
-title: Docs | Changelogsync ant task
-subnav: subnav_documentation.md
----
-
-# changeLogSync Ant Task
-
-Marks all change sets as ran against the database. Useful when you have manually updated your database.
-
-## Parameters
-
-
