How to Version Modules Depending on Different Framework Versions

Should I release these packages with different version names using Semantic Versioning? In my opinion, yes, but what about the naming of these different versions?

You should not change the version unless your code changes. However, your current approach of appending the library version works fine under the rules of Semantic Versioning, but you have to use a + sign to add the library dependency:

• 1.0.0
• 1.0.0+json-c-0.10

For realeasing, and assuming your package name is purestjson this gives:

• purestjson-1.0.0
• purestjson-1.0.0+json-c-0.10

Rationale: Semantic Versioning states in rule 10:

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

In practice, it is difficult to release a new database version. While it is nice to have a module with the current DDL, in many cases you will likely be modifying an existing database. I would keep it as a separate module.

The practice for DDL that I use, is to generate an upgrade (and downgrade) script for each release. Changes that break the current release (deletions and new constraints) get deferred until the next release. There are some other consideration that allow two releases to work with a database version. These scripts include the DML release they apply to in their name.

Most of your DML should work over a wide range of versions. It is possible that you will have many DML releases without DDL changes. In other cases, you may have DDL changes to resolve performance issues that have no corresponding DML changes.

If you tag your code in your version control system, it really doesn't matter much which of the two modules changed. Unless you check-in a version identifier, it is OK to have multiple tags on the same code.

EDIT: I've taken a quick look at flyway. I don't think it significantly alters the above recommendations. I would suggest making your application DML dependencies allow the DDL version to increase. I wouldn't want to break my application by adding an index, column, or table. (DDL changes may include DML to update data which should be in the same repository as the DDL.)

Consider deprecating columns and tables that are being dropped. You should be able to use text search on the DML to identify and remove use deprecated objects. This should allow you to test some regressions without having to regress the database.