-
Notifications
You must be signed in to change notification settings - Fork 79
[RFC] Software Release Management Proposal #8
Comments
Hi Malte/Ionel, a gentle nudge regarding getting your feedback/comments on the proposed release process for Firmament codebase. We look forward to hearing from you. Accordingly, we will proceed with follow on steps within CAMSA/Firmament environment. Thanks. Regards, cc: @shivramsrivastava @timothysc @ICGog @ms705 @dhilipkumars |
The proposed release process looks fine to me, although it seems unnecessary to have Firmament and Poseidon releases necessarily be in lockstep (there may be no need to cut a Firmament release if nothing has changed). However, if it simplifies things and @ICGog agrees, that's fine by me. Presumably the later sections of the document are still to come? |
Agree Malte, release process should detect this and create a new release for Firmament or Poseidon only if there are any changes made to them. We will keep that in mind once we start building out the release process. thanks. |
Yes, I agree. I see no reason why do couple the Firmament and Poseidon releases. The other thing worth mentioning is that we're already using Travis CI to build after each commit and run the tests Poseidon CI. I think we should probably extend that CI, unless we have better CI alternatives. This CI is also configured to show nice code coverage. |
Hi Ionel, thanks for your comment. Although, I am confused a bit. IIUC, what you are suggesting is that we keep Poseidon unit testing coverage in Travis CI. What we are currently planning is the following:
Please let me know, if this makes sense. Thanks. |
@ms705 and @ICGog, Kubernetes ecosystem has built its own CI / CD pipeline jobs and bots which is far more friendly to K8s specific jobs. Like bringing up a k8s cluster and running tests against it. etc., We will endup doing a lot of work if we had to replicate what the k8s ci system is currently doing. Plus the cluster environments are sig sponsored. we could keep the travis ci as additional verification step. We do not propose to change firmament CI system. The reason we proposed to align Poseidon's and Firmament's release cycle as close as possible because more releases down the line it might become a lot harder to map which version of Poseidon works well with which version of Firmament. This release coupling is temporary until firmament has its own big community and starts following a specific release cycle on its own. (in parallel we are also working to simplify the whole installation process using helm/chart that would automatically resolve version mapping). If you want a different release cycle (frequency and versioning) for firmament what would that be? |
ref: #helm/charts#4479 |
@shivramsrivastava is in the process of incorporating a new section on the main read.me page that captures all details for coordinating Firmament & Poseidon repos. He should be done soon. |
See the following link for description of coordinated release process in order for Firmament & Poseidon repos to work together in lockstep. We also incorporated all this as part of the read.me page. Closing this issue now. https://github.com/kubernetes-sigs/poseidon/blob/master/docs/releases/release-process.md |
Hi All,
Here is the initial draft of software release management workflow for Poseidon and Firmament.
https://docs.google.com/document/d/1rUkFFD4JB-jDjZhWv62El0_6h7o89GawIIjzNDa0Lyo/edit?usp=sharing
cc: @shivramsrivastava @timothysc @ICGog @ms705 @deepak-vij
The text was updated successfully, but these errors were encountered: