update ff cli to main

[EnriqueL8]

No description provided.

[peterbroadhurst]

I was looking back and I don't think take this approach recently @EnriqueL8

So probably needs thinking through and comparing to how we've done it with releases in the past.

(even if the only change is to the PR comment to describe how we've managed this in the past, the implications, and how we're planning to do it going forwards)

[EnriqueL8]

The manifest.json file stores all the version for a particular release so in the case of v1.3.0 we updated it will the v1.3.0 versions of each of the components: data exchange 1.3.0, etc...

Given that this file is in main I think we should be keeping a reference to the main components especially the FireFly CLI if not we would constantly be releasing new version of the sub components too keep up to date with it and it will become inconsistent with the version of FireFly.

I could release a new FireFly CLI v1.3.1 but that wouldn't match the release cadence of FireFly. I wonder if the decision is to we want to keep the repos as consistent as possible or each component should release it's own versions and their manifest.json in main should just point to the latest release version?

We use this manifest.json in a couple of ways:

• As part of the CI pipeline
• In the FireFly CLI, it will be checkout a tag v1.3.0 and uses the image digests in the manifest.json to deploy the stack.

[awrichar]

I strongly disagree with using an indeterminate reference for anything in the manifest. If I run a build on Tuesday, and retry the exact same build on Wednesday, it could be using a completely different version. That's bad - the point of the manifest is reproducibility.

We have always either used tagged releases or specific builds generated from main. So we don't have to do a release of the CLI, but we do need to point at one specific version rather than just "main".

[awrichar]

In terms of versioning in general:

• Each commit to a subproject generates a new build
• Subprojects try to align minor version number with FireFly (ie 1.3) but perform patch releases as needed (1.3.1, 1.3.2, etc would be a release because that particular project has a patch... we won't try to align 1.3.1 across everything, because it's not like all projects will need patching at the same time)
• In between FireFly releases, the mainline manifest may point to specific/unreleased versions of subprojects (but always a specific version for reproducibility and traceability)
• When we release FireFly, the manifest should have only released versions of subprojects

[EnriqueL8]

Makes sense - will point it a specific commit of the FireFly CLI and I couldn't agree more with

Subprojects try to align minor version number with FireFly (ie 1.3) but perform patch releases as needed (1.3.1, 1.3.2, etc would be a release because that particular project has a patch... we won't try to align 1.3.1 across everything, because it's not like all projects will need patching at the same time)

[awrichar]

Seems OK to me. For the record, I see that you're pointing at https://github.com/hyperledger/firefly-cli/commits/1378d838891cd0a43d9a255dac9b707a69f13c59, which corresponds to the point where hyperledger/firefly-cli#308 was merged.

[EnriqueL8]

Yes, thought it would pick that fix as well