Prepare for 0.3.0

[thepetk]

Please specify the area for this PR

N/A

What does does this PR do / why we need it:

This PR prepares the release-v0 for the v0.3.0 release.

Which issue(s) this PR fixes:

Fixes devfile/api#1605

PR acceptance criteria:

• Test Coverage
  • Are your changes sufficiently tested, and are any applicable test cases added or updated to cover your changes?
• Gosec scans
  • Fix all MEDIUM and higher findings and/or annotate a finding per gosec instructions: https://github.com/securego/gosec#annotating-code to address why a finding is not a security issue

Documentation

• Does the registry operator documentation need to be updated with your changes?

Testing changes

Running Unit Tests

Running Integration Tests

Special notes to the reviewer:

[michael-valdron]

Also ignore failures with k8s checks as we still need k8s compatibility in our integration tests devfile/api#1313.

[Jdubrick]

We should hold this release until #93 is merged so the release can contain the critical sev fix

[michael-valdron]

We should hold this release until #93 is merged so the release can contain the critical sev fix

@Jdubrick I agree, though since these are only prep changes in the release branch and the release will not be cut until the release branch is merged into main so we can continue with this PR.

@thepetk The second PR to merge this target branch into main should be on hold until #93 is merged so we can include that fix in this release.

[thepetk]

We should hold this release until #93 is merged so the release can contain the critical sev fix

@Jdubrick I agree, though since these are only prep changes in the release branch and the release will not be cut until the release branch is merged into main so we can continue with this PR.

@thepetk The second PR to merge this target branch into main should be on hold until #93 is merged so we can include that fix in this release.

I've added a blocker label on devfile/api#1620 for devfile/api#1605. Once the registry-library is bumped up I'll remove the it :)

[thepetk]

@Jdubrick @michael-valdron an attempt to merge the 0.3.0 release-v0 branch to main.

[Jdubrick]

@Jdubrick @michael-valdron an attempt to merge the 0.3.0 release-v0 branch to main.

Is this in an effort to try and fix the git log? Maybe I misheard but I thought we were moving to having separate release branches?

[michael-valdron]

@Jdubrick @michael-valdron an attempt to merge the 0.3.0 release-v0 branch to main.

Is this in an effort to try and fix the git log? Maybe I misheard but I thought we were moving to having separate release branches?

@Jdubrick I see that we have documented it in devfile/api#1516 and this is still the case that each release would have their own release branch. I think that this should follow our other repositories release processes though where the release is cut in main then its release branch is created if a major, or minor as suggested recently. Patches should be merged in after release.

The release branches should be used for backports, so if we wanted to patch prior feature versions we can backport changes and cut patch releases under the release branches.

[thepetk]

@Jdubrick @michael-valdron an attempt to merge the 0.3.0 release-v0 branch to main.

Is this in an effort to try and fix the git log? Maybe I misheard but I thought we were moving to having separate release branches?

This merge IMO is required to have an up-to-date tree for the main branch. The release branch will open once we merge the release-v0 to main and it will include the minor version too (e.g release-v0.3) to support potential backported fixes.

cc @michael-valdron

[thepetk]

@Jdubrick @michael-valdron an attempt to merge the 0.3.0 release-v0 branch to main.

Is this in an effort to try and fix the git log? Maybe I misheard but I thought we were moving to having separate release branches?

This merge IMO is required to have an up-to-date tree for the main branch. The release branch will open once we merge the release-v0 to main and it will include the minor version too (e.g release-v0.3) to support potential backported fixes.

cc @michael-valdron

:D Actually @michael-valdron was faster and more verbose than me

[Jdubrick]

@Jdubrick @michael-valdron an attempt to merge the 0.3.0 release-v0 branch to main.

Is this in an effort to try and fix the git log? Maybe I misheard but I thought we were moving to having separate release branches?

This merge IMO is required to have an up-to-date tree for the main branch. The release branch will open once we merge the release-v0 to main and it will include the minor version too (e.g release-v0.3) to support potential backported fixes.

cc @michael-valdron

Ah okay, so this merge is a one-time git tree fix and moving forward each release is going to have its own release branch used for backports but we are tagging and releasing from main?

[michael-valdron]

@Jdubrick @michael-valdron an attempt to merge the 0.3.0 release-v0 branch to main.

Is this in an effort to try and fix the git log? Maybe I misheard but I thought we were moving to having separate release branches?

This merge IMO is required to have an up-to-date tree for the main branch. The release branch will open once we merge the release-v0 to main and it will include the minor version too (e.g release-v0.3) to support potential backported fixes.
cc @michael-valdron

Ah okay, so this merge is a one-time git tree fix and moving forward each release is going to have its own release branch used for backports but we are tagging and releasing from main?

In most cases yes, except for backport releases in prior feature versions.

[thepetk]

@Jdubrick @michael-valdron an attempt to merge the 0.3.0 release-v0 branch to main.

Is this in an effort to try and fix the git log? Maybe I misheard but I thought we were moving to having separate release branches?

This merge IMO is required to have an up-to-date tree for the main branch. The release branch will open once we merge the release-v0 to main and it will include the minor version too (e.g release-v0.3) to support potential backported fixes.
cc @michael-valdron

Ah okay, so this merge is a one-time git tree fix and moving forward each release is going to have its own release branch used for backports but we are tagging and releasing from main?

Yeah, the difference here is we close once and for all the release-v0 branch and once merged we cut release-v0.3. For next releases, we won't do the same as we will have already cut release-vx.x for the release.

[thepetk]

@michael-valdron / @Jdubrick thoughts for the review?

[michael-valdron]

I'd suggest bringing in up to my recent commit as well: 85ef7f3

[thepetk]

I'd suggest bringing in up to my recent commit as well: 85ef7f3

@michael-valdron I've rebased my branch to current main. Out of curiosity, is it necessary to go through the process again? I'm thinking the extra commit is a doc update. Just to have more context on what the release process is including :)

[michael-valdron]

I'd suggest bringing in up to my recent commit as well: 85ef7f3

@michael-valdron I've rebased my branch to current main. Out of curiosity, is it necessary to go through the process again? I'm thinking the extra commit is a doc update. Just to have more context on what the release process is including :)

@thepetk Just wanted to include updates to requirements to show up to date expectations for the release. I think this should be it for this release. 🙂

[thepetk]

I'd suggest bringing in up to my recent commit as well: 85ef7f3

@michael-valdron I've rebased my branch to current main. Out of curiosity, is it necessary to go through the process again? I'm thinking the extra commit is a doc update. Just to have more context on what the release process is including :)

@thepetk Just wanted to include updates to requirements to show up to date expectations for the release. I think this should be it for this release. 🙂

@michael-valdron nice thanks! Feel free to review!

[Jdubrick]

lgtm

Should get @michael-valdron approval as well

[thepetk]

lgtm

Should get @michael-valdron approval as well

Yeah +1 might seem to be small but we're actually rebasing a lot of stuff :)

[michael-valdron]

Just need to pin the version hashes for the go install commands and the rest lgtm.

[thepetk]

Just need to pin the version hashes for the go install commands and the rest lgtm.

Yeah I was planning to open a new issue on this as it's out of scope for this issue. But I did a quick pass and I've added pins everywhere. I did the same for the gosec to be consistent with all others.

[michael-valdron]

/lgtm

Changes looks good for release, running bash check_version.sh produces:

All version tags match!

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Jdubrick, michael-valdron, thepetk

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Jdubrick,michael-valdron,thepetk]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment