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.
Beta 4 of Liquibase 2.0 is now available from http://www.liquibase.org/download
The major improvement over beta 3 is the fact that it will actually run…
Other improvements include:
<column> and <addDefaultValue>
If you have any issues or questions, please let us know
We are down to the final days of the extension contest, but there is still time to get your entry in for a chance to win great prizes.
See the extension portal for full details.
Liquibase 2.0 Release Candidate 1 is now available from http://www.liquibase.org/download
The primary focus of the 2.0 release is extensibility and building community. In particular, this means infrastructure changes such as:
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.
<modifyDataType> or other more specific comands (addPrimaryKeyConstraint, etc.) and/or include the modifyColumn library in your classpath.The new format looks like:
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd">
Please give Liquibase 2.0 a try and report any issues or questions you have.
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
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.
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:
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 (http://liquibase.org/ci/latest). 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.
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:
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:
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.
Wow, it has been a very long time since RC1, but we finally are ready for RC2. It can be downloaded from http://liquibase.org/download 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 at http://liquibase.org/v2_features.
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.
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.
2.0 RC3 is now available. Like always, you can download it from http://liquibase.org/download.
RC3 includes:
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
2.0 RC4 is now available. Like always, you can download it from http://liquibase.org/download.
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…
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 http://liquibase.org/download
Looking for feedback and interest. See the forum post for more information or to post your thoughts.
Hopefully the last RC release before 2.0. As always, you can download it from http://liquibase.org/download.
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.
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 http://liquibase.org/download and report issues to http://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
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.
Teradata support is now available as an extension for Liquibase 2.0. The extension was created by Xavier Poinsard and can be downloaded from http://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
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 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.
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, <modifySql> 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.
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:
Beyond the big goals of extensibility and community (and the bug fixes), there is also important new functionality in the core Liquibase library including:
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.
If you visit http://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.