Summary: | [NEW PORT] databases/p5-App-Sqitch: Sane database management | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Sarah Hodne <freebsd> | ||||
Component: | Individual Port(s) | Assignee: | Kurt Jaeger <pi> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | pi | ||||
Priority: | --- | Keywords: | feature, patch-ready | ||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Bug Depends on: | 205944 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Adding dependency to p5-URI-db port addition, which this port depends on. testbuilds@work Testbuilds look fine. No changes needed for 0.9994, so... Added TEST_DEPENDS, make test looks fine. A commit references this bug: Author: pi Date: Sun Apr 10 10:37:37 UTC 2016 New revision: 412912 URL: https://svnweb.freebsd.org/changeset/ports/412912 Log: New port: databases/p5-App-Sqitch Sqitch is a database change management application. What makes it different from your typical migration-style approaches? A few things: ## No opinions Sqitch is not integrated with any framework, ORM, or platform. Rather, it is a standalone change management system with no opinions about your database engine, application framework, or development environment. ## Native scripting Changes are implemented as scripts native to your selected database engine. Writing a PostgreSQL application? Write SQL scripts for psql. Writing a MySQL-backed app? Write SQL scripts for mysql. ## Dependency resolution Database changes may declare dependencies on other changes -- even on changes from other Sqitch projects. This ensures proper order of execution, even when you've committed changes to your VCS out-of-order. ## No numbering Change deployment is managed by maintaining a plan file. As such, there is no need to number your changes, although you can if you want. Sqitch doesn't much care how you name your changes. ## Iterative development Up until you tag and release your application, you can modify your change deployment scripts as often as you like. They're not locked in just because they've been committed to your VCS. This allows you to take an iterative approach to developing your database schema. Or, better, you can do test-driven database development. WWW: http://search.cpan.org/dist/App-Sqitch/ PR: 205943 Submitted by: Henrik Hodne <henrik@hodne.io> Changes: head/databases/Makefile head/databases/p5-App-Sqitch/ head/databases/p5-App-Sqitch/Makefile head/databases/p5-App-Sqitch/distinfo head/databases/p5-App-Sqitch/pkg-descr head/databases/p5-App-Sqitch/pkg-plist Sorry that this took that long. It's now in the tree. |
Created attachment 165134 [details] p5-App-Sqitch-0.9993.shar Note: This depends on p5-URI-db, which isn't in the ports tree yet (and that again depends on p5-URI-Nested, which also isn't in the ports tree). I'll submit ports for those in the next few minutes as well, and link them here. From pkg-descr: Sqitch is a database change management application. What makes it different from your typical migration-style approaches? A few things: No opinions Sqitch is not integrated with any framework, ORM, or platform. Rather, it is a standalone change management system with no opinions about your database engine, application framework, or development environment. Native scripting Changes are implemented as scripts native to your selected database engine. Writing a PostgreSQL application? Write SQL scripts for psql. Writing a MySQL-backed app? Write SQL scripts for mysql. Dependency resolution Database changes may declare dependencies on other changes—even on changes from other Sqitch projects. This ensures proper order of execution, even when you’ve committed changes to your VCS out-of-order. No numbering Change deployment is managed by maintaining a plan file. As such, there is no need to number your changes, although you can if you want. Sqitch doesn’t much care how you name your changes. Iterative development Up until you tag and release your application, you can modify your change deployment scripts as often as you like. They’re not locked in just because they’ve been committed to your VCS. This allows you to take an iterative approach to developing your database schema. Or, better, you can do test-driven database development.