Tag Version Policy

[tiokim]

It would be great if we push container images to docker hub frequently whenever any PR is merged.
The general semantic version control policy is as follows:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

However how about increasing the PATCH version when PR (except refactoring and document update) is merged?
We can deploy container images frequently in this manner.

[tdrozdovsky]

I fully agree with @t25kim. Just wanted to offer to do it (I indicated that in the v1.1.1 version were fixed vulnerabilities).
Please note that all tags must be signed (git tag -s v1.1.1).

[tdrozdovsky]

We can also check the correct setting of the requested parameters (DOCKERHUB_USERNAME, DOCKERHUB_PASSWORD).

[tdrozdovsky]

I would also like to ask why was the v2 (2.0.0) label created?. Since we still do not know whether our version will have v2.0.0 or v1.2.0? I think that the optimal option is to come up with a name for the next release (for example: Elderberry or other)

[MoonkiHong]

@lf-edge/edge-home-orchestration-go-maintainers Recommend to use v2.0.0 once we fully support all the subordinate components from our Home Edge platform architecture. Before touching that milestone, I would like to recommend to use v1.2.0 for our next major release. Thought?

[tdrozdovsky]

I agree with @MoonkiHong to use v1.2.0 (maybe v2.0.0 if in the next release a condition is performed "MAJOR version when you make incompatible API changes")

[tiokim]

@lf-edge/edge-home-orchestration-go-maintainers Recommend to use v2.0.0 once we fully support all the subordinate components from our Home Edge platform architecture. Before touching that milestone, I would like to recommend to use v1.2.0 for our next major release. Thought?

This idea is good. However if we move DataStorage to the another repository(#415), we may need to increase Major number due to API changes. I hope that all subcomponents will be implemented in vE.

[MoonkiHong]

@tdrozdovsky What about volunteering to release v1.1.1 for gathering PRs by today? After your initiation, we will refer to your experience. Thoughts? 🙏

[suresh-lc]

I understand the point of major version release when there is API level changes. But as @MoonkiHong had mentioned, when new features are added to make the platform complete, new APi's would be added and hence it would qualify as major release. Till then we can have our sub versions.
How about listing what all components we plan to have as part of vE.

[tdrozdovsky]

@tdrozdovsky What about volunteering to release v1.1.1 for gathering PRs by today? After your initiation, we will refer to your experience. Thoughts? 🙏

Yes, I'll do it. But it would be good in order to include PR #424 (for synchronization with a container on Docker Hub) in this tag.

[tiokim]

1. Release Home Edge v2 if it fully supports all the subordinate components.
2. Increase MINOR number in the official release before v2.
3. Increase PATCH number and push the tags frequently.

[MoonkiHong]

@lf-edge/edge-home-orchestration-go-maintainers From now on, I will create a tag in a weekly basis with the regarding commit (versioning update) every Friday if we have PR(s) in that week.