Skip to content

kickcat: add version v2.3-rc3 #27256

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

trns1997
Copy link
Contributor

@trns1997 trns1997 commented Apr 17, 2025

Summary

Changes to recipe: kickcat/ v2.3-rc3


@trns1997
Copy link
Contributor Author

ping @leducp

@trns1997 trns1997 marked this pull request as draft April 17, 2025 18:26
@trns1997 trns1997 marked this pull request as ready for review April 17, 2025 18:41
@trns1997 trns1997 marked this pull request as draft April 17, 2025 18:58
@trns1997 trns1997 marked this pull request as ready for review April 28, 2025 15:07
@jcar87
Copy link
Contributor

jcar87 commented Jun 4, 2025

Out of curiosity - what is the release strategy for this library?
We don't tend to add pre-releases - find it a bit odd that every version after 1.0.0 seems to be a release candidate - are there actual releases?

@leducp
Copy link
Contributor

leducp commented Jun 4, 2025

Well, it depends on the POV, but this library is currently used by our medical device (exoskeleton) and is as such under really long verification and validation process.
We see releases as final version that follow all our internal criteria for critical softwares and it can takes months/years, and we do not 'release' intermediate rc if we cannot prove them under this processus. However, we do use release candidate as 'release with less proof' so yes, it is a release :)

@jcar87
Copy link
Contributor

jcar87 commented Jun 4, 2025

Does that mean that no version since October 2021 has actually passed this rigorous validation process?
Just trying to understand - when we include things in Conan Center, we assume they have wide use or there is wider interest in the community, and we tend to avoid including pre-release software.

@leducp
Copy link
Contributor

leducp commented Jun 5, 2025

I think it is just a naming convention that differ: we put in release candidate 'production ready code' and we put them in release when they are 'safety critical production ready'.
I understand that this naming scheme is not really communicative outside of the company... I can push an evolution in naming for our open source projects if you think it worth it, maybe something like x.y.z and x.y.z-safety? If you have insight for the naming they are welcomed as we don't have many outside perspective.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants