Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update default VERSION in makefile to 0.0.1-latest #200

Closed
wants to merge 1 commit into from
Closed

Update default VERSION in makefile to 0.0.1-latest #200

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion Makefile
View file
Open in desktop
Expand Up @@ -3,7 +3,7 @@
# To re-generate a bundle for another specific version without changing the standard setup, you can:
# - use the VERSION as arg of the bundle target (e.g make bundle VERSION=0.0.2)
# - use environment variables to overwrite this value (e.g export VERSION=0.0.2)
VERSION ?= 0.0.1
VERSION ?= 0.0.1-latest
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @coreydaley ! But now the tags for the PR images sound a bit confusing to me :/

PR images are available:

  1. quay.io/janus-idp/operator:0.0.1-latest-pr-200-ae0f223
  2. quay.io/janus-idp/operator-bundle:0.0.1-latest-pr-200-ae0f223
  3. quay.io/janus-idp/operator-catalog:0.0.1-latest-pr-200-ae0f223

Also, I think that with the changes here, once this PR is merged, the next-container-build workflow would end up creating images like this: quay.io/janus-idp/operator:0.0.1-latest-latest-$sha or quay.io/janus-idp/operator:0.0.1-latest-next-$sha, which will make it more confusing to me.

Maybe we should just build and push the tag for the base version (0,0,1, which would be considered the latest) besides the other tags? So I'd suggest keeping the base version as it is, but changing https://github.com/janus-idp/operator/blob/main/.github/workflows/next-container-build.yaml#L88-L114 to push the tag for the base version. WDYT?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point
I think we should not have "0.0.1" version yet as it is not released yet but we probably need to have "latest" aliased to the last PR's image.
I.e. something like this (for this example):
operator:pr-200-ae0f223 (having 0.0.1 prefix looks redundant to me)
and
operator:latest - pointed to the same image (latest for the time)
And when we release 0.0.1
operator:0.0.1 (plus we may have some alias like "stable" for the latest released)

WDYT?
CC @nickboldt

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, make release-build does require a semantic version, so with Major.Minor.Patch elements:

$ make VERSION=pr-200-`git rev-parse --short HEAD` release-build
[...]
Error: invalid command options: pr-200-ae0f223 is not a valid semantic version: No Major.Minor.Patch elements found

I think that's why we added the additional labels and build metadata to the version.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rm3l I see, I missed this point.
So we can keep it as it is (0.0.1-pr-200-ae0f223) for PR release + tag "latest" for the latest one?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gazarenkov we can not simply use VERSION := latest as otherwise we have similar semantic version error:
"Error: invalid command options: latest is not a valid semantic version: No Major.Minor.Patch elements found"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So after discussing this, we think it would make sense to:

This way, this PR won't be needed, and make deploy would work out of the box.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So after discussing this, we think it would make sense to:

This way, this PR won't be needed, and make deploy would work out of the box.

@rm3l This sounds good to me. Further considerations for discussion:
a) In the master branch, set VERSION ?= 1.1.0-dev (In this way the images from master and release branches will never have conflict).
b) In the release branch 1.1.x, set VERSION ?= 1.1.0

Copy link
Member

@rm3l rm3l Feb 16, 2024 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jianrongzhang89 Following the discussion yesterday about versioning of the CR, I'm wondering if we should not still keep 0 as major here as well (to make it clear that it is not stable version yet - (only RHDH version is 1.x.y))?
So:

  • 0.0.1 as it is in the release branch 1.1.x
  • but 0.0.1-dev on main

WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rm3l it makes sense to use major version 0, but I think we should use a minor version instead of a patch version:
0.1.0 as it is in the release branch (and we should rename the branch to 0.1.x to match them),
but 0.1.0-dev on main.

Releases with bugfixes can be released as 0.1.1 etc, releases with new features can be 0.2.0 etc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. But I would keep the 1.1.x release branch name as it is for now, as I'm not sure about the implications on the downstream build pipelines..


# Using docker or podman to build and push images
CONTAINER_ENGINE ?= docker
Expand Down