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

Standardization of HDF5 Library Tarball File Naming Structure #4944

Open
HathewayWill opened this issue Oct 10, 2024 · 0 comments
Open

Standardization of HDF5 Library Tarball File Naming Structure #4944

HathewayWill opened this issue Oct 10, 2024 · 0 comments
Assignees
Labels
Component - Build CMake, Autotools Priority - 1. High 🔼 These are important issues that should be resolved in the next release Type - Improvement Improvements that don't add a new feature or functionality
Milestone

Comments

@HathewayWill
Copy link

Feature Request: Standardization of HDF5 Library Tarball File Naming Structure

Problem Description: The current file naming convention for HDF5 library tar files lacks consistency across different versions, causing frustration for developers who rely on automation tools to download and update the library. For instance, version numbers are often formatted differently, with variations such as:

1.14.4
1.14.4-1
1.14.4.3
1.14.5
These inconsistencies require developers to constantly update their scripts to accommodate the varying file names, introducing unnecessary complexity and potential errors into their workflows. For automated processes, this variability disrupts the downloading and unpacking of tar files, requiring manual intervention or constant adjustments to the automation scripts.

Proposed Solution: To streamline and standardize the file naming structure, I propose adopting a uniform naming convention for all future HDF5 library releases. This would involve always including redundant subversion numbers, even in cases where there may not be any updates or patches. This consistent format would ensure that file names across all versions adhere to a predictable pattern, simplifying automated workflows.

For example, the file naming structure could follow one of the formats below:

1.14.0.0
1.14.0_0
1.14.0-0
This standardization will guarantee consistency, making it easier for developers to script around a fixed format. Even if a version does not have additional updates or patches, the file name will remain predictable and uniform.

Benefits:

Consistency: A standardized naming structure across all releases ensures that developers do not need to modify their scripts for each new version.
Automation-Friendly: This solution would greatly benefit those relying on automated scripts for downloading and managing HDF5 updates, reducing manual intervention and the risk of errors.
Backward Compatibility: Developers could easily script for future versions without worrying about varying naming patterns.
Alternative Solutions Considered: Renaming the tar files after downloading has been considered but poses additional challenges, such as creating inconsistencies during unpacking and potential mismatches with the contents or other dependencies. This solution would introduce even more complexity into the automation process and is not ideal for most use cases.

In summary, adopting a consistent and predictable file naming convention would greatly improve the developer experience and reduce frustration by simplifying the management of HDF5 library updates.

@bmribler bmribler added Component - Build CMake, Autotools Type - Improvement Improvements that don't add a new feature or functionality labels Oct 10, 2024
@derobins derobins self-assigned this Oct 11, 2024
@derobins derobins added this to the 2.0.0 milestone Oct 15, 2024
@derobins derobins added the Priority - 1. High 🔼 These are important issues that should be resolved in the next release label Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component - Build CMake, Autotools Priority - 1. High 🔼 These are important issues that should be resolved in the next release Type - Improvement Improvements that don't add a new feature or functionality
Projects
None yet
Development

No branches or pull requests

4 participants