Define a versioning pattern

[sebailfico]

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.

[GitGab19]

The workflow I proposed some weeks ago is the following:

• on the core and frontend repos the development branches are used to push new commits between a release and another
• when we want to do a release, we open a PR from the development branches to the respective main ones
• after that, we create the release on both repos
• then we push a new commit on this repo (app) to update the submodules with latest main branches
• we do the release from this app

Is 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]

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]

My question was more about: should we have a version also on this repo(app)?

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 app repo.

When we're ready for the official first release, this is what I expect to see:

• core repo --> release v0.1.0
• frontend repo --> release v0.1.0
• app repo --> push a new commit to update the submodules and then do release v0.1.0.

Does it fit your thoughts as well?

[b-rowan]

Easiest way to do this in my experience would be set it on the FastAPI app, so:

app = FastAPI(
    version=importlib.metadata.version("edge-mining")
)

Then you can create a route for the version:

@app.route("/version")
async def app_version(request: Request) -> str:
    return request.app.version

[sebailfico]

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]

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]

@riccardoaran you got it!

In the future we could have scenarios where core and frontend versions diverge, but we will always maintain their compatibility in the app, by making releases in the app repo.

[sebailfico]

Great, sounds like we have a plan