Proposal to release current HEAD of main as release v0.8.0

[hdamker]

@jpengar @eric-murray @patrice-conil @shilpa-padgaonkar

As discussed within the call on Friday I propose to create our first Github release v0.8.0 with the current HEAD of main (commit 61200f1). This is currently the unchanged v0.8.0 of the QoD API definition from mid of October + the updated documentation.

All other PRs can then going again into main. After the fixes are applied we can declare a v0.8.1 release and then go on with the larger changes (including PR #67).

In addition (and before creating the v0.8.0 release) I propose to create a "historic" pre-release v0.1.0 based on the commit which I tagged already as v0.1.0. It represents then the initial contribution and allows to describe the changes in v0.8.0. It has to be done before as Github as the timestamps and sorting of the releases can't be changed afterwards.

Let me know if I should go forward with these proposal and create the two releases v0.1.0 and v0.8.0.

[eric-murray]

Will a release just be the API definition + relevant documentation, or will it be a snapshot of the whole repository? If the latter, I'd prefer that the "legacy" implementation for v0.1.0 be moved to QualityOnDemand_PI1 first before creating the 0.8.0 release.

Proposal to create a "historic" 0.1.0 release is fine, though maybe we need some comment about why there is no 0.2.0 through to 0.7.0.

[jlurien]

I'm OK with the creation of release 0.8.0, and then we can move to 0.8.1 with the already identified typos and notificationUrl renaming. Also with saving relevant past versions in the history.

I also think that moving the legacy implementation by DT to the _PI1 repo is cleaner.

[shilpa-padgaonkar]

I agree to the proposal of creating the two releases, v0.1.0 and v0.8.0.

Please refer here https://github.com/camaraproject/WorkingGroups/pull/123

IMHO, we don't need the legacy implementation of 0.1.0 in new PI repo for DT

[eric-murray]

IMHO, we don't need the legacy implementation of 0.1.0 in new PI repo for DT

This is an internal matter for Deutsche Telekom, but the implementation code needs to be removed from the main QualityOnDemand repository, especially if the whole repository is considered to form a release

[shilpa-padgaonkar]

It's completely fine to remove it from the main QoD repo.

[hdamker]

Agree to delete the implementation code from v0.1.0 before declaring v0.8.0. Will create a PR for that. The code will not be lost ... it is still included within v0.1.0. Within in the provider implementation (PI_1) repo we will start with 0.8.x API.

[hdamker]

@jpengar @eric-murray @patrice-conil @shilpa-padgaonkar Please have a view on the drafted releases at https://github.com/camaraproject/QualityOnDemand/releases. Will wait for at least one feedback before publishing.

[jpengar]

@jpengar @eric-murray @patrice-conil @shilpa-padgaonkar Please have a view on the drafted releases at https://github.com/camaraproject/QualityOnDemand/releases. Will wait for at least one feedback before publishing.

(cc @jlurien)

I don't see any release in QualityOnDemand/releases.

[sfnuser]

@hdamker, All - My assumption is that a 'release' constitutes the API definition + relevant documentation and the software (Provider Implementations) can have their own releases/versioning. Could you please clarify?

[jlurien]

@jpengar @eric-murray @patrice-conil @shilpa-padgaonkar Please have a view on the drafted releases at https://github.com/camaraproject/QualityOnDemand/releases. Will wait for at least one feedback before publishing.

Don't see anything there:

[hdamker]

@SfnUser

All - My assumption is that a 'release' constitutes the API definition + relevant documentation and the software (Provider Implementations) can have their own releases/versioning. Could you please clarify?

Yes, that is also my understanding and one of the reasons why we moved the provider implementation(s) into separate repositories.

[hdamker]

@jpengar @jlurien Just checked it and learned that draft releases are ony visible for users with push access. As I have a review from Shilpa and as it is possible to edit the release description afterwards, I will now publish the two releases. We can continue to discuss them here.

Going forward it might make sense to agree on releases via a pull request on a changelog (which we need still to create) and use the merge of this pull request a) as the commit of the release and b) the text as the description of the release.

[hdamker]

Release v0.8.0 is done and documented in https://github.com/camaraproject/QualityOnDemand/blob/main/CHANGELOG.md