Ability to further organize versions

Feature Suggestions
1

Quick Description

In addition to the current version history, the ability to label or tag a version could be useful for aligning them with important updates, like migrations for example.

Skip to Summary for a condensed list of ideas

Additional Notes

Extra actions could also be taken when certain versions are created. Perhaps screenshots of the diagram can be generated linking to major versions. iframe’s don’t render in markdown on Github, but a link to an image will. If there is a static link always pointing to the latest major version’s screenshot (similar to embed links), it wouldn’t require continued setup to keep the repo’s image in sync with the current state of the database and diagram.

The API definitely opens the door to develop a type of versioning, but at the moment I think it would have to be managed locally by the user. Something along the lines of creating a cli tool manages everything.

For example:

  1. User finishes updating a diagram and is ready to make database updates.
  2. User runs command that creates files like <db-name>-1.0.dbml and <db-name>-1.1.dbml that get saved in Github repo.

But it feels like this route would add a lot of unneeded complexity. From the outside looking in, it seems like with the new changlelog and API updates, a lot of the information is starting to be there.


I also think it could compliment the new API in a few ways:

  • As far as I can tell, the API does not currently handle or return any type of version information, it only returns the latest changes. Even if you aren’t able to query for every single version, having API access to important versions could be very useful for automation tools.

  • I’ve developed an npm package that uses the API and works great for automating the setup of a database based on a dbml file. However, it currently only works for new project setup and handling migrations after the initial setup will be much more difficult to add. Knowing exactly which versions to compare would make this process much easier to automate.

  • Adding in something like Github Actions (similar to dbdocs) or webhooks could then be used to automatically generate pull requests or issues related to new major version creation. Even without screenshots, there are a couple dbml rendering tools that could be used to generate an image that could be saved and referenced locally in markdown (though I’m still looking for one that can take advantage of the X and Y position the API provides).

Summary

Dream updates:

  • Ability to add tags to versions. i.e. Major, Minor, etc.
  • Add tags and version number to API. In responses and as query options for filtering, i.e.:
    • query for specific version
    • query for latest version
    • if_newer and if_newest, query params to reduce payload size of responses if version check is required while requesting diagram content. Could also be in CI/CD to easily check for major version changes
  • An endpoint for version metadata, i.e. latest, history, tags, changelog data, etc.

Dreamier updates:

  • Add ability to customize what happens on events related to tags, i.e:
    • Add a webhook that gets hit anytime a Major version is created. This would be great for ease and reducing server load when using API with automated workflows
    • Show some type of alert or notify diagram editors
  • Add dbdocs fancy beta changelog data to API return for diagram data
    • Being able to easily link to a specific changelog or the wiki could be very useful for organizing a task list when new changes are ready to be made in development, especially if combined with automatically created issues
    • In my case, I’m using Sequelize and sequelize-cli to automate my setup process. The ability to reference a changelog (especially if one could be generated that compared major versions) would be huge for automating a bulk of the migration process.
    • My workflow also generates a markdown file containing the steps required to verify automations worked correctly and finish any additional setup required. Being able to reference changelogs would greatly assist in the creation and accuracy of this checklist.