Extensibility Roadmap 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.
>
>  
>
> 1.       More Extensibile API:
>
> a.       Ability to override what SQL is sent to the database for
> standard databases and refactorings
>
>                                                                i.      
> Add engine innodb to all create table statements
>
>                                                              ii.      
> LoadData on MSSQL should call “set identity insert on/off”
>
> 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 3^rd 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 3^rd 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?  Is there anything you
> would like to volunteer tackling?
>
>  
>
> 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.
>
>  
>
> Nathan
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Liquibase-devel mailing list
> Liquibase-devel@...
> https://lists.sourceforge.net/lists/listinfo/liquibase-devel

> 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.
>
>  
>
> 1.       More Extensibile API:
>
> a.       Ability to override what SQL is sent to the database for
> standard databases and refactorings
>
>                                                                i.      
> Add engine innodb to all create table statements
>
>                                                              ii.      
> LoadData on MSSQL should call “set identity insert on/off”
>
> 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 3^rd 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 3^rd 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?  Is there anything you
> would like to volunteer tackling?
>
>  
>
> 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.
>
>  
>
> Nathan
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Liquibase-devel mailing list
> Liquibase-devel@...
> https://lists.sourceforge.net/lists/listinfo/liquibase-devel