Skip to content

version numbers in 1 file #77

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

Closed
vincentsijben opened this issue Mar 24, 2025 · 3 comments · Fixed by #84
Closed

version numbers in 1 file #77

vincentsijben opened this issue Mar 24, 2025 · 3 comments · Fixed by #84
Assignees
Labels
enhancement New feature or request

Comments

@vincentsijben
Copy link
Contributor

Describe the feature or enhancement

In the new library template the pretty version has to be edited inside buid.gradle.kts. The incremental (integer) version inside release.properties. Before this template I think everything was in 1 file.

What is the use case?

It feels a bit off to go to 2 files to change a version. Seems like a minor thingy, but when both version things were next to eachother it didn't felt so bad haha 😄

Alternatives considered

I understand the incremental version is used for the inner workings of the contribution manager, but it would be great if for instance (only?) the release number in the GItHub release could/would be used for versioning.

@vincentsijben vincentsijben added the enhancement New feature or request label Mar 24, 2025
@mingness
Copy link
Collaborator

Thanks @vincentsijben , this is a good call. There are two things here, the contributor experience of editing two files, and then the use of the fields version and prettyVersion.

For the contributor experience of editing two files, I recall that we want to set the version in the build file, which is a fundamental property like the group id, we must consider of the order that gradle files are processed. When we were designing this template, we opted for simplicity and fewer files, but I'll look for a solution that improves contributor experience, even if that means we need an additional file.

Regarding the two version fields, this is related to how the contributions manager works. My understanding is that we currently need both versions, but perhaps @Stefterv might be able to chime in here.

@mingness mingness linked a pull request Mar 29, 2025 that will close this issue
@mingness
Copy link
Collaborator

mingness commented Apr 2, 2025

@vincentsijben thanks for this suggestion, it is now implement. We'd be happy for you to feedback on the change, and if it indeed streamlines the interaction with the files.

@vincentsijben
Copy link
Contributor Author

vincentsijben commented Apr 4, 2025

@vincentsijben thanks for this suggestion, it is now implement. We'd be happy for you to feedback on the change, and if it indeed streamlines the interaction with the files.

works like a charm! Allthough we still need to do 2 things:

  • increment/change the GitHub release version (that will be used as the prettyVersion).
  • increment the "version" inside release.properties.

It would be too much of a change (I guess) to use the proper MAJOR/MINOR versioning system to also calculate an integer for the "version" property, right? Then we would only have to think of 1 (correct) GitHub release version, so we end up with a nice prettyVersion (the same as the GitHub release) ánd Processing Contribution Manager would know if there's an update. But then again, not everyone uses GitHub 😄

But I'm definitely happy with this update ❤

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

Successfully merging a pull request may close this issue.

2 participants