-
Notifications
You must be signed in to change notification settings - Fork 4
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
Creating a new release doesn't set the version #64
Comments
Nice one! The database currently is designed to store values direct from the properties file, for ease of comparison, and logic. Any overwrites of values is stored in the override field, usually being static manual overrides. The pretty version from the release could be stored in the prettyVersion field, replacing the value in the properties file, or be stored in the override field. Which is more logically intuitive for you? I keep flip flopping. |
This is more about the library template than the contributions repo. Here are the following steps:
Screen.Recording.2025-01-11.at.10.31.07.movThis is what I did to create a new release. That results in the following assets: The version in myLibrary.txt is 1.0.0. This can be fixed by setting the version in the |
Are you saying, you'd like myLibrary.txt to be edited when creating release artifacts, such that the release tag replaces the value of prettyVersion in the properties file? |
I'd say so, this is how it works for processing https://github.com/processing/processing4/actions/runs/12300574818/workflow and I think we can see from Alex's example that is what people expect |
I'm not sure if it's what people expect, but it certainly is an automation we could provide. |
Describe the bug
I noticed that Alex's Shape Mapper reported being version 1.0.0 in the contributions manager even though the released version is v0.1.5. I tracked it down to the fact that the version is not overridden in the GitHub Action. I think for user-friendliness we should add that part
Steps to reproduce
Create a new release with a version different than what is set in the
build.gradle.kts
Expected behavior
The version should be derived from the release tag
Actual behavior
The version is derived from what is in the
build.gradle.kts
The text was updated successfully, but these errors were encountered: