Version update for development

[sarthakpati]

Fixes #N.A.

Proposed Changes

• added -dev to version
• only publish nightly if dev was found in version

Checklist

• I have read the CONTRIBUTING guide.
• My PR is based from the current GaNDLF master .
• Non-breaking change (does not break existing functionality): provide as many details as possible for any breaking change.
• Function/class source code documentation added/updated.
• Code has been blacked for style consistency.
• If applicable, version information has been updated in GANDLF/version.py.
• If adding a git submodule, add to list of exceptions for black styling in pyproject.toml file.
• Usage documentation has been updated, if appropriate.
• History has been updated, if appropriate.
• Tests added or modified to cover the changes; if coverage is reduced, please give explanation.
• If customized dependency installation is required (i.e., a separate pip install step is needed for PR to be functional), please ensure it is reflected in all the files that control the CI, namely: python-test.yml, and all docker files [1,2,3].

[github-actions]

MLCommons CLA bot All contributors have signed the MLCommons CLA ✍️ ✅

[sarthakpati]

Curious if it would make sense to add -dev to the pip nightly publish [ref] instead of having -dev in the version.py file itself. This would let us not have to maintain the -dev ID in the version.py file.

Thoughts?

@AlexanderGetka-cbica @Geeks-Sid @hasan7n @aristizabal95

[AlexanderGetka-cbica]

The only consequence I see is that this means that the repo itself will not track whether or not the code is in dev or a release version. So there will be multiple commits in the history where e.g. “version = 0.17.0” but the code itself won’t specify whether that is a release, only the tag metadata from Git/GitHub will do that. As is currently, if the version is left *without* “-dev” in the source and the nightly publishing triggers, the nightly publishing will actually publish something that isn’t a prerelease. Oops, didn’t anticipate that. If there is no other input I can do this tonight before the Nightly triggers. From: Sarthak Pati ***@***.***> Sent: Tuesday, May 16, 2023 10:41 AM To: mlcommons/GaNDLF ***@***.***> Cc: Subscribed ***@***.***> Subject: [External] Re: [mlcommons/GaNDLF] Version update for development (PR #648) Curious if it would make sense to add -dev to the pip nightly publish [ref<https://github.com/mlcommons/GaNDLF/blob/master/.github/workflows/publish-nightly.yml#L54>] instead of having -dev in the version.py file itself. Thoughts? — Reply to this email directly, view it on GitHub<#648 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOHRPDTAJC376WS2IFMOQH3XGOGV5ANCNFSM6AAAAAAYDYDE4E>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[codecov]

Codecov Report

Merging #648 (aea457a) into master (7335258) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #648      +/-   ##
==========================================
+ Coverage   94.32%   94.33%   +0.01%     
==========================================
  Files         114      114              
  Lines        7677     7677              
==========================================
+ Hits         7241     7242       +1     
+ Misses        436      435       -1     

Flag	Coverage Δ
unittests	94.33% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
GANDLF/version.py	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[sarthakpati]

The only consequence I see is that this means that the repo itself will not track whether or not the code is in dev or a release version.

I think this is going to be the major downside. Let's see what the others think.

[hasan7n]

Could this help? I saw it used by the numpy package

[sarthakpati]

Could this help? I saw it used by the numpy package

This makes a lot of sence. Let's make this as a longer-term discussion, perhaps in conjunction with whatever versioning mechanism we will use with medperf?

[Geeks-Sid]

I believe it is crucial to carefully consider this issue's downside. I'm pleased to see the "dev" tag, as it indicates that the feature is currently under development. However, I propose that we expand our tag system by incorporating additional tags such as "-rc" for release candidates. We could also benefit from introducing tags like "nightly" and "stable," but this would require adhering to release schedules. For instance, we could aim to release stable versions at the end of each month and nightly builds on the 15th. Before granting approval for this request, I would appreciate further discussion on these suggestions. Thoughts from everyone are welcome, maybe something that can be discussed on common calls.

[sarthakpati]

I believe it is crucial to carefully consider this issue's downside. I'm pleased to see the "dev" tag, as it indicates that the feature is currently under development. However, I propose that we expand our tag system by incorporating additional tags such as "-rc" for release candidates. We could also benefit from introducing tags like "nightly" and "stable," but this would require adhering to release schedules. For instance, we could aim to release stable versions at the end of each month and nightly builds on the 15th. Before granting approval for this request, I would appreciate further discussion on these suggestions. Thoughts from everyone are welcome, maybe something that can be discussed on common calls.

Yes, these are things we should discuss during the weekly call. I unfortunately won't be there today, but I can discuss this next week. For now, let's get this merged in?

[AlexanderGetka-cbica]

Approving so that the version on PyPI is stable and not being pushed by master. Let's revisit this next time we speak.