Replies: 3 comments 2 replies
-
|
It's incredibly frustrating that you've opted to only support OCI helm registries which are not well adopted/supported in the ecosystem. I would like to propose that a standard Helm Registry is created and utilized instead. |
Beta Was this translation helpful? Give feedback.
-
|
I'll convert this to a discussion as I think it's more of that than an issue based on what you've offered. There's a bit to unpack here, but at a high-level, I'll say that we aim to have more stable versions of the Router published once we reach 1.0.0, but I also don't believe that's unintuitive considering we're using Semantic Versioning 2.0 on the project, as indicated at the top of our More details in the discussion. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
At a more detailed level to my above response, I think it will be valuable for posterity to respond to your individual points in case someone is curious about this in the future, so I'll take the time to respond within:
The helm chart released today is Both
It goes on to indicate:
We note our commitment to using semantic versioning to convey the stability of our releases at the top of our
Going back to the above statement, this wording indicates a breaking change can simply exist in pre-release versions. Our If Helm tooling mis-led you into thinking that there would be no breaking change on a pre-release version or didn't pin the version to a range that you specified, that seems like it could be a failure in Helm's tooling or versioning strategy or your usage of that tooling? I suspect if you remained on version 0.9.0 things and didn't bump to
I believe the terminology "alpha" is common convention in software along with "beta" and "prerelease". You shouldn't feel compelled to use alpha releases if you don't want to. You should evaluate your own comfort level with adopting versions of software. I think thankfully, you can use semantic versioning as a guide to help interpreting that comfort. Known issues are opened by the community on this repository to highlight specific challenges and up-voted accordingly when they are shared by others, so you can evaluate those when making a decision. We tend to prioritize the most painful things and course-correct accordingly.
Router 0.9.0 was indeed GA — which means general availability. That "GA" designator doesn't negate the semantic versioning version numbers which we have applied to our releases. Referring back to the semantic versioning specification again:
The
We're not doing anything esoteric or ad-hoc here: Our updates and changes are on our releases page and duplicately outlined on our I'll flag that this comment seems a bit demanding to me. When we're openly abiding by common conventions like semantic versioning and CHANGELOGs in expected locations, I'll claim the burden of highlighting discrepancies to common convention is on you. I suggest you look holistically at the deltas you're observing compared to other software projects rather than analyzing us and questioning us in isolation. At a meta level, since I do believe we're obeying common conventions in software releasing, I am going to ask you to not come here requesting that we explain those things to you. If you feel differently, I'm curious why.
You're welcome to host the chart yourselves, but this comment seems off-topic and unrelated to this issue and more along the lines of another issue you've previously opened: The outcome of that seemed to indicate that I hope the above is overall helpful information in understanding the releasing strategy we have employed. If you feel my claims are off, I'm interested in understanding better. As a last point that is not specifically about releasing strategy, this is the second time now that I've observed you using the language that I find to be a bit insensitive on this repository. There are people behind this GitHub repository working on this software and even if we weren't shipping software in the prescribed way I described above, coming here and opening issues with titles like "Using the OCI Helm Repository is impossible" is, I think, lacking some empathy in the words that were chosen. In that other case my feeling is that the title seems editorialized, it's phrased as a frustration, and the root cause might be something else entirely. (Personally, I can't subscribe to it being fundamentally impossible, because Helm built it and seems to support OCI-based charts with This new topic then uses phrasing that I think pushes us to explain the way we're shipping releases as if they're particularly different without even claiming how they're different or offering concrete or actionable suggestions for improvement about the strategy for us to reason about. As a reminder, we have a code of conduct that is in force on this entire organization and would prefer a bias toward positivity. |
Beta Was this translation helpful? Give feedback.
-
|
@abernix I appreciate the details but I think what needs to happen is not an in-depth explanation of topics I already understand, but a roadmap or more communication to your end users. I would appreciate less condescension and more documentation and communication with your end-users. For example, where are any of these transitions and nuances apparent to someone looking at your repository for the first time? I don't need to go back and forth with you on the things you've brought up. In some case you're right, in some you arent. In all cases, I've felt dismissed. The issues you've brought up in the past were closed without any resolution in my opinion. What do you want me to do when all it seems like you care about is controlling issue count? You're entirely correct that the title is phrase by frustration. Why don't you try to find out why that might be? I have been frustrated from the start working in Apollo's ecosystem (see the entire arm64 binary debacle, which by the way is still in progress) and I have been repeatedly dismissed on that issue and several others. I understand you're supporting an open source project but you're also a private company and ultimately want people to pay for your projects. I don't understand the dismissal and frankly rude behavior I've observed communicating with Apollo's projects. Maybe there is a thread to pull there? Why don't we start there? |
Beta Was this translation helpful? Give feedback.
-
|
I would also like to apologize for anything I have said that has been lacking empathy or has seemed insensitive. That was not my intention at all. I know we're all busy people and we're all trying our best. Hopefully we can find an understanding and move forward. |
Beta Was this translation helpful? Give feedback.
-
Describe the solution you'd like
I am thoroughly confused by ya'lls release strategy.
alphaalphatagging, did things regress?We are pinned to v0.16.0 at the moment which is not compatible with the most recent helm chart version (the
supergraphconfiguration key). Please explain what's going on here and how we should follow updates. We are unfortunately not able to use the OCI Helm Repo and version properly so I guess we'll have to resort to hosting the chart ourselves for the time being?Beta Was this translation helpful? Give feedback.
All reactions