Repository navigation
Define a versioning pattern #2
Description
Talking with @riccardoaran we've realized that it would be very useful to see the main version of "Edge Mining" from the frontend.
We've discussed about few paths but the best options is to talk about it togheter with @markoceri and @GitGab19 to choose where and how to set the version(which repo, tag-based, commit based etc.) and how to show it in the frontend(footbar etc).
In the meanwhile everyone's welcome to elaborate a practical/phylosophical approach to solve this need.
Reacted by Riccardo | ARAN
Activity
GitGab19 commentedon Jan 7, 2026
The workflow I proposed some weeks ago is the following:
coreandfrontendrepos the development branches are used to push new commits between a release and anothermainonesapp) to update the submodules with latestmainbranchesIs this answering your question?
About the graphical part, we can put the release version in the footbar as you mentioned, which points to the release on this repo (`app).
One last general note about versioning: I would stick with the standard SemVer rules (https://semver.org/)
sebailfico commentedon Jan 8, 2026
Thanks for the asnwer.
My question was more about: should we have a version also on this repo(app)?
Because, as you said, at the moment the core and frontend have 2 different versions which can grow on their own indipendently from the other.
@riccardoaran suggested we may keep a versioning of the app repo, which is the one from which we will distribute the 2 submodules as a single package.
This may allow us to synchronize the submodules versions and to show to the users a single, unified version number, which may be easier to manage.
I hope I was clear, please tell me what you think about
GitGab19 commentedon Jan 8, 2026
Yes, sure.
Every time we do a release, that's gonna follow the SemVer rules, and we are gonna assign a version number to it.
We are gonna version all three repos, but the end-user will only care about the version of the
apprepo.When we're ready for the official first release, this is what I expect to see:
corerepo --> releasev0.1.0frontendrepo --> releasev0.1.0apprepo --> push a new commit to update the submodules and then do releasev0.1.0.Does it fit your thoughts as well?
b-rowan commentedon Jan 8, 2026
Easiest way to do this in my experience would be set it on the
FastAPIapp, so:Then you can create a route for the version:
sebailfico commentedon Jan 8, 2026
Thanks both, I think it makes sense but in a way it forces the same versions for the 3 repos, which becomes redundant, despite being meaningful nonetheless. Do you think it would add any meaning to the project to have separate milestones or versions?
@b-rowan I like it, I just add how I usually do with Vue webapps. I update the packages.json of the frontend and then pack it in the webapp, like with VITE you could add to the vite.config.json the following:
define: { __APP_VERSION__: JSON.stringify(process.env.npm_package_version) }And then use it as an environment variable
const version = __APP_VERSION__riccardoaran commentedon Jan 9, 2026
I think @GitGab19 message (core v0.1.0 / frontend v0.1.0 / app v0.1.0) is just an example for the first coordinated release, not a proposal to lock versioning between repos forever.
Core and frontend should keep their own independent SemVer, evolving at different speeds while app should have its own “product” version (the one we show to end users)
So after the first release it would be normal to have something like:
core 1.4.2
frontend 0.9.0
app 0.6.0 (the version users see)
And in the UI we can show the app version in the footer, while optionally exposing core/frontend versions
GitGab19 commentedon Jan 9, 2026
@riccardoaran you got it!
In the future we could have scenarios where
coreandfrontendversions diverge, but we will always maintain their compatibility in the app, by making releases in theapprepo.sebailfico commentedon Jan 9, 2026
Great, sounds like we have a plan