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.

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

Releases for version 0.4 and 0.5 are missing #682

Open
pkvprakash opened this issue Sep 14, 2023 · 4 comments
Open

Releases for version 0.4 and 0.5 are missing #682

pkvprakash opened this issue Sep 14, 2023 · 4 comments

Comments

@pkvprakash
Copy link

pkvprakash commented Sep 14, 2023

Releases for version 0.4 and 0.5 are missing in GitHub. It will be useful for dependency manager tools like vcpkg to fetch the sources and do a build from source if we have these releases also linked to the reposotory.

@mshr-h
Copy link

mshr-h commented Oct 22, 2024

@hcho3 @tqchen Building Apache TVM from source on OpenSUSE is failing due to the lack of the new release of dmlc. Could you please release the new version?
apache/tvm#17459

@hcho3
Copy link
Contributor

hcho3 commented Oct 22, 2024

Currently, downstream packages (TVM, XGBoost, DGL etc) reference a specific commit of dmlc-core via git submodules. Given these projects have different development cycle, we would need to create daily rolling releases. We can use a GitHub Actions workflow like https://github.com/marketplace/actions/automatic-releases to automate the task.

Would you be okay if dmlc-core had daily rolling releases (e.g. 0.6-{some date} for each date where there was a change)?

@mshr-h
Copy link

mshr-h commented Oct 23, 2024

I'm okay with the rolling release. Maybe including the commit hash (e.g. 0.6-3031e4a) can be more consistent.
@ggardet Do you have any comment regarding the rolling release?

@ggardet
Copy link

ggardet commented Oct 23, 2024

I'm okay with the rolling release. Maybe including the commit hash (e.g. 0.6-3031e4a) can be more consistent. @ggardet Do you have any comment regarding the rolling release?

The commit hash in version is not suitable because it will be impossible to know if version 0.6-3031e4a is greater or lower than 0.6-a4e1303.
So, 0.6-{YYYYMMDD} would be better.

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

No branches or pull requests

4 participants