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

Create initial release of csi-driver-iscsi #4

Open
saad-ali opened this issue Feb 15, 2019 · 14 comments
Open

Create initial release of csi-driver-iscsi #4

saad-ali opened this issue Feb 15, 2019 · 14 comments
Assignees
@humblec
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@saad-ali
Copy link
Member

  1. Do some manual testing to ensure the driver works as intended.
  2. Create a release-0.1 branch for kubernetes-csi/csi-driver-iscsi
  3. Cut an official release v0.1.0 release of this driver from the new branch.
  4. Push a csi-driver-iscsi:v0.1.0 container (either to quay or gcr.io whatever the Kubernetes CSI team decides)
@saad-ali
Copy link
Member Author

CC @msau42 @prateekpandey14

@msau42
Copy link
Collaborator

msau42 commented Feb 15, 2019

Before we do that, we should also:

  • Use release-tools for common process
  • Remove dependency on csi-lib-common

cc @pohly

@pohly
Copy link
Contributor

pohly commented Feb 15, 2019

I was about to suggest the same as @msau42.

One comment about branching: it is not necessary to start such a branch right away. The initial release can also be done from the master branch and then (if necessary) a maintenance branch can be created later.

@saad-ali
Copy link
Member Author

One comment about branching: it is not necessary to start such a branch right away. The initial release can also be done from the master branch and then (if necessary) a maintenance branch can be created later.

Sure. As long as we cut a branch before the next release. I want to make sure that we never end up with a situation where an older release does not have a branch that we can go back to and make patch fixes.

@pohly
Copy link
Contributor

pohly commented Feb 18, 2019

Sure. As long as we cut a branch before the next release. I want to make sure that we never end up with a situation where an older release does not have a branch that we can go back to and make patch fixes.

I just don't understand what you are worried about here. What would prevent creating that branch at a later time, when it is needed?

We can have v1.1.0, v1.2.0, v1.3.0 all tagged on master, with no branches. When we decide that we need a v1.1.1 with a certain bug fix from master, we create a release-1.1 branch off v1.1.0 and backport that fix. Then v1.1.1 is tagged on that branch.

pohly pushed a commit to pohly/csi-driver-iscsi that referenced this issue Feb 20, 2019
@k8s-ci-robot
Merge pull request kubernetes-csi#4 from pohly/canary-fix
be8a440 
build.make: fix pushing of "canary" image from master branch
@msau42
Copy link
Collaborator

msau42 commented Feb 20, 2019

cc @j-griffith

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 21, 2019
@msau42
Copy link
Collaborator

msau42 commented May 22, 2019

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 22, 2019
@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 20, 2019
@msau42
Copy link
Collaborator

msau42 commented Aug 20, 2019

/lifecycle frozen

@k8s-ci-robot k8s-ci-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Aug 20, 2019
@humblec
Copy link
Contributor

humblec commented Apr 22, 2021

@saad-ali @msau42 I would like to take up this task .

@humblec
Copy link
Contributor

humblec commented Apr 22, 2021

/assign @humblec

@humblec humblec mentioned this issue Apr 23, 2021
Closed
@humblec humblec mentioned this issue Sep 9, 2021
Closed
@humblec
Copy link
Contributor

humblec commented Feb 10, 2022

We now have v0.1.0 here https://github.com/kubernetes-csi/csi-driver-iscsi/releases/tag/v0.1.0 , once we have e2e in place we will be releasing v1.0.0

@andyzhangx
Copy link
Member

v1.0.0 is for GA release, once we have e2e test, we could claim it's beta release with v0.2.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@humblec humblec

Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[WIP] Add deployment artifacts for iscsi csi driver deployment humblec/csi-driver-iscsi
7 participants
@pohly @andyzhangx @humblec @saad-ali @k8s-ci-robot @msau42 @fejta-bot