[Feature request] Design whole-repo versioning scheme

[eddelbuettel]

Is your feature request related to a problem? Please describe.

TileDB-SOMA is a monorepo containing three distinct components. Of these only one (the Python package) currently has a well-defined, visible, and exported version number.

Describe the solution you'd like

All three components should have a version. Ideally the same version reflecting the same repository state and release tag.

As the C++ library is a required component of the Python package which already has a version, it is a natural candidate to be versioned next. This should cover both internal use (have an accessor function returning the version number, say the triplet <1,2,4> if the version is 1.2.4) and external by installing versioned with a major.minor scheme. We already follow a semantic versioning scheme so there is little extra needed to enable it as cmake is supporting this for other builds such as TileDB Core.

The R package can join the party once matured to release status '1.0'.

Describe alternatives you've considered

N/A

Additional context

N/A

[mlin]

@eddelbuettel This is a bit of a tangent, but, do I understand correctly from this r-universe FAQ that it's only possible to install the very latest build from r-universe?

---

---

(where the link describes a scheme that I think may, with the right setup, automate resolving an older version to the original git sources and trying to build them; but that's very unlikely to work well for a package like tiledbsoma with a complex build process)

If so, I'm wondering about our path to publishing the R package in a way that dependent packages like cellxgene.census can ensure an expected/compatible version. Is CRAN the answer to that? Another idea (since iteration time with CRAN is a concern) might be to create multiple r-universe packages, each set to build from a different branch of this repo, and maintain internally-stable lineages on those branches.

(We can break this off into a separate issue if it's too much of a diversion from the main point here!)

cc @pablo-gar @ebezzi @aaronwolen @mojaveazure

[eddelbuettel]

This is a bit of a tangent,

Yes and yes 😀 We have no control over r-universe other than option to participate or not (as well as which packages). There is now how in the sense of 'one version, or five, or all' of a participating package. The most recent one it iis.

Moreover the R community does not have that per se. CRAN is very explicitly 'at HEAD' where everythiing is current and tested. install.packages() has no version argument. Neither does update.packages(): it just checks 'is there a newer one'.

Installng additional older version from somewhere else are add-on services from someone else such as using GitHub tags or releases, or fetching an older version from, say, the CRAN archive page. (I believe remotes does all three.) Then there are MRAN (disappearing) and now PPM/RSPM offering download by date using add-on services.

So all that is a little off-topic for this issue which concerns itself chiefly with the fact that neither the C++ library has a version nor the R version.

But more than happy to help with the other issue! Open for DM and chat, another issue, a call. I may have ideas.

[mlin]

Thanks @eddelbuettel -- taking this tangent over to #1427