-
Notifications
You must be signed in to change notification settings - Fork 53
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.
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
[DISCUSS] Do we want to keep dev tests as strict filter for Ecosystem member #448
Comments
@frankharkins @Eric-Arellano I would like/need to have your point of view here please :) |
Update their code. This means that, in 3 months of less, it will stop working with stable.
True. But our current main is pre-release. You could install from main and fix it. Ideally, we could have a "warning" when deprecation warnings show up. The warning should tell the user how to fix their code.
I think this is easy to fix, by installing
I'm good with it. Even stable can be information, as the "promise" of the member only applies to standard check. |
Indeed, I forget that this is the way to do before changing feature. And Ecosystem already track the warning and depreciation logs during check.
Hmm, it's already what we are doing. We first install the project requirements ( Maybe I don't see what you mean @1ucian0 🤔 ?
Cool :) |
oops. I mean uninstalling
This might be a too-high bar, given the current state of the ecosystem. Take mitiq for example, a well maintained project that compatible-release-pin qiskit (using But I dont have a strong opinion, just my two cents :) |
Oh ok, I'll test that.
Ooook I see, thanks for the release plan PR I'll read that.
Your two cents are very good to better understand where Qiskit goes and how can we follow with the Ecosystem and external projects (at least for me) 😃 Let's wait @frankharkins opinion to see where we gonna go. I think we already have some tracks we can easily apply. |
(Sorry, I was away and took a while to catch up.) I vote to make stable and dev tests optional. Updating every few months is a lot of work with qiskit changing so quickly. These checks should be FYI to the maintainer. I'm still looking at the requirements problem to form a better opinion. |
Ok ok, I'll make the evolved in the CI |
Conclusion of the discussion
We only keep the standard check as struct filter and change dev and stable as informational.
About the requirement problem, it was part solved in the PR #447, then make dev and stable optional gonna solve the next blocking part
TODO:
Requirement problemToday's situation
Today when a project is submitted 3 checks are running :
qiskit-terra
qiskit-terra
If we are agree than stable and standard check are mandatory, what about the dev check ?
Initially, we created this check because of the fast development of
terra
and the breaking changes problemqiskit
could have. And so, it was a way to make sure the project not gonna break with the next release.Positif
Having dev check allows to make sure the project is working well with at least 2 versions of
terra
, the actual and the next one. Who are pretty cool and anticipate the breaking changes and the fast development ofterra
.Negatif
If the project doesn't pass the next release, what can do the maintainer of the project ?
From my knowledge we don't have documentation of development release or even for pre-release. So how can we help maintainer to make their project pass ?
Other⚠️
Each
Qiskit
version need a specific version ofterra
and so we always have these logs during the setup ofqiskit-terra
dev version :We choose to not check
ERROR
logs during the setup phase and so this doesn't break the process but it's pretty bad to haveERROR
log as normal situation.Conclusion
My point of view would be to still have the dev check during submission but not as mandatory, as informational.
If stable and standard check passed. The submission would be succeeded.
If the dev check doesn't passed, an information comment would be post and notify the maintainer that its submission passed but it not gonna pass for the next release and so he gonna need to update its project when the next release gonna be launch.
Of course, that's only my understanding of the situation. And my point of view maybe doesn't work with the vision Qiskit maintainers have of the Ecosystem.
The text was updated successfully, but these errors were encountered: