Versioning conventions for DAR packages

Questions
1

Hi,

Experimental versions of the SDK are versioned as e.g. 2.3.0-snapshot.20220611.10066.0.458cfc43.

The same does not seem to apply to user-created DAR packages, where the version is constrained to the regular expression ^(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))*$. This prevents users from tagging pre-release packages as e.g. version: 3.0.0-snapshot-20220616 in the daml.yaml file.

Is there another recommended approach to deal with experimental / pre-release packages in the case of DAR packages?

Thank you,
Matteo

2

Is it ever a good idea to upload experimental or pre-release packages to a non-sandbox ledger?

If not, I think 0.0.0 is a pretty good choice for such a version.

If so, or there is some other technical reason 0.0.0 cannot be used, I think you’ll have to pick your own convention. This is just a personal preference, but I suggest for the pre-release of x, using (x-1).96 as the pre-release series, in honor of this historical curiosity of the GCC release history.

1 Like
3

@Stephen, thanks for your reply.

We would like the ability to put characters in the version name like snapshot for most of the same reasons the daml SDK utilises such naming conventions. Using snapshot or RC1 or RC2 in the version name is pretty much industry standard in library versioning and it’s must more self evident than 0.0.0 or 2.0.96.

4

Hi @Brian_Weir,

Unfortunately the format restriction on Daml package version numbers is a constraint of the underlying Haskell tooling Daml is built upon, and is very much non-trivial for us to fix.

The best workaround I can suggest is to notice that the number of figures in the version string is not limited by the regex (or the underlying tooling), so you could use a longer string for snapshots, e.g. including the date:

0.1.2.20220615.1

This is actually close to (I don’t remember the exact details) what we do under the hood when versioning our own Daml packages (e.g. the standard library) for snapshot releases of the Daml SDK.

2 Likes
5

Thanks for the feedback and the suggestions @Stephen.

I second Brian’s comment that the ability to append characters in the version name would come in handy.

As for background, this would be used to manage dependencies across Daml projects. These experimental packages will (hopefully) not find their way onto non-sandbox ledgers.

Matteo

6

Thanks for the context @Gary_Verhaegen and the suggestion! :+1: