DKAN is a Drupal-based open data tool with a full suite of cataloging, publishing and visualization features that allows governments, nonprofits and universities to easily publish data to the public. It is inspired by the CKAN project and maintained by Granicus Data.
- Publish data through a guided process or import via API/harvesting from other catalogs
- Customize your own metadata fields, themes and branding
- Store data within DKAN or on external (e.g. departmental) sites
- Manage access control, version history with rollback, RDF support, user analytics
- Supported enterprise-quality commercial support and FISMA-certified cloud hosting options available
- Explore, search, add, describe, tag, group datasets via web front-end or API
- Collaborate with user profiles, groups, dashboard, social network integration, comments
- Use metadata and data APIs, data previews and visualizations
- Manage access control, version history with rollback, INSPIRE/RDF support, user analytics
- Extend and leverage the full universe of more than 18,000 freely available Drupal modules
Granicus Data platform offers 24/7, secure, cloud-based DKAN hosting and support services.
Please see the "Installation" section of the DKAN Documentation.
Please see the "Updating and Maintaining DKAN" section of the DKAN Documentation for general upgrade information.
Check the releases page for latest DKAN Version. 7.x-1.x is the development branch.
Contact us if you want to get involved!
DKAN development is a sponsored by NuCivic. For more information about hosting and professional support options for DKAN, see http://getdkan.com/contact
DKAN follows a modified semantic versioning convention, and has major, point (also known as minor), and patch releases.
The only major release of DKAN has been 7.x-1.0. It is unlikely there will be a 7.x-2.x version of DKAN but in the case of a major architecture change, this is possible. More likely is a 8.x-2.x release if and when DKAN is ported to Drupal 8. At the moment there is no work being done on a Drupal 8 version.
Point releases occur approximately every 1-2 months and include new functionality and architectural changes. For instance, DKAN 7.x-1.1 was the first point release, and 7.x-1.2 was the second. While we try to make updating as seamless as possible, point release updates often involve some work, especially if the website uses a custom theme or modules outside of what is included in the distro.
Patch releases, introduced after the release of DKAN 7.x-1.12, occur much more frequently, and include bug fixes, core and contrib module updates, and minor enhancements. The first patch release was version 7.x-1.12.1, the second was 7.x-1.12.2, and so on. Updating to a new patch release should be very straightforward and cause little to no distruption to a website.
After a point release comes out, we create a release branch, on which we do any work intended for future patch releases on that version of DKAN. The release branch for version 7.x-1.12 development, for instance, is release-1-12. New features and other work destined for the next point release continues on the main development branch, 7.x-1.x.
We keep the DKAN profile (this project), DKAN Dataset, DKAN Datastore, DKAN Workflow and Recline versioning in sync. Other depdendencies that we maintain, incuding Open Data Schema Map and Visualization Entity follow their own, separate release cycle.
Have a question, found a bug, or need help with DKAN? Check our documentation first. In addition:
Please post a question on our Developer list.
Please post it to our Github issue queue.
Please contact us for a consultation.
While the GovDelivery Open Data team leads the DKAN project, there is a worldwide community behind it contributing ideas and code. You are welcome to join the discussion:
Please file all tickets for DKAN in this issue queue. We have several labels in place for you to tag the issue with and identify it with the proper component.
Please follow the Ticket Template when creating new tickets.
Also, please remember to reference the issue across repositories in order for maintainers to pick up commits and pull requests looking at the issue. You can do that for commits like this:
git commit -m "Issue NuCivic/dkan#<issue_number>: ..."Just replace <issue_number> with the actual issue number. You can reference pull requests exactly like that if you add the same text "NuCivic/dkan#<issue_number>" in a comment.
This really help us detecting changes and pulling them in in faster.