Skip to content

How to handel to leading "v" in the PyGMT release number? #4790

Closed

Description

@yvonnefroehlich

Initial comments

Currently we use a leading "v" in the PyGMT release number. However, the sematic versioning concept does not support this, xref: https://semver.org/#is-v123-a-semantic-version.

For release 0.8.0, we decided to drop the "v" in the BibTeX entry in the README to be consistent with the CITIATION.cff file (https://github.com/GenericMappingTools/pygmt/pull/2272/changes#diff-7b3ed02bc73dc06b7db906cf97aa91dec2b2eb21f2d92bc5caa761df5bbc168f). But we still use it in the meta data for the Zenodo archive:

Image

Thus, it is included in the cititation suggested by Zenodo, e.g., https://doi.org/10.5281/zenodo.3781524:

Tian, D., Leong, W. J., Fröhlich, Y., Grund, M., Schlitzer, W., Jones, M., Toney, L., Yao, J., Tong, J.-H., Magen, Y., Materna, K., Belem, A., Newton, T., Anant, A., Ziebarth, M., Quinn, J., He, X., Uieda, L.& Wessel, P. (2026). PyGMT: A Python interface for the Generic Mapping Tools (Version v0.19.0) [Computer software]. Zenodo. https://doi.org/10.5281/zenodo.19398871

Futuremore we use the "v" in the GitHub releases and tags and the file name for the Zenodo archive as well as in the table for the Minimum Supported Versions. It's also proposed in the Maintainers Guide.

We should think about whether we want to drop the "v" completely or, if not, where (and why) we still want to use it. Also need to update the Maintainers Guide afterward correspondently.

Handling by other projects

Activity

  1. added this to the 0.20.0 milestone on Aug 2, 2026
  2. seisman commented on Aug 9, 2026

    @seisman
    Member

    Just want to add some more background here.

    In SemVer v1.0.0, it's clear that it recommended tagging a release with a leading v (xref: https://semver.org/spec/v1.0.0.html#tagging-specification-semvertag). This tagging recommendation was later removed in SemVer v2.0.0 mainly because (semver/semver.org#1):

    it is out of scope how tags are setup for the different version control systems.
    And: Each developer team can use any kind of tag scheme for their version control system, e.g. "v1.2.3" or "release-1.2.3" or "v1.2.3-foo" as long as the embedded SemVer tuple conforms to the SemVer spec.
    Using the bare SemVer Tuple is just an easy to parse and also the most simple option. But using a prefix like 'v' can help to "just disambiguates (it) a little more than the straight version number by itself."

    GitHub also recommends a leading v in tags (Click the "Draft a new release" button on the Release page, then you'll see the message on the right side):

    It’s common practice to prefix your version names with the letter v. Some good tag names might be v1.0.0 or v2.3.4.

    So, from what I understand, 0.19.0 is the version number that follows SemVer, while v0.19.0 is the version string to refer to the software tag or release.

    Currently, the PyGMT version is used in the following places (feel free to make edits if you find more).

    The "Correctness" column indicates whether the current version string follows the strict definition mentioned above. ✅ means correct; ❌ means incorrect; ❓ means unsure or doens't matter.

    Case Current Version String Correctness What others do
    Tag names v0.19.0 ✅ numpy: v2.5.2; pandas: v3.0.5; xarray: v2026.07.0
    Release title v0.19.0 ❓ pandas: 3.0.5, numpy: v2.5.1 (July 4, 2026), xaray: v2026.07.0
    Documentation URL v0.19.0 ❓ pandas: 2.1, numpy: 2.5, xarray: v2026.07.0
    pygmt.__version__ v0.19.0 or v0.19.0.dev5+gabcdef ❌ pandas: 2.1.0, numpy: 2.5.1, xarray: 2026.7.0
    Dreprecation messsage in source codes v0.19.0 ❓ Remove the leading v?
    version field in CITATION.cff 0.19.0 ✅
    BibTeX version filed in doc/citing.md 0.19.0 ✅
    Minimum Support Versions v0.19.0 ❓ Remove the leading v to be more consistent with version string of other packages?
    Changelog section title Release v0.19.0 ❓ numpy: NumPy 2.5.0 Release Notes; pandas: Version 3.0; xarray: v2026.07.0 (Jul 9, 2026)
    pygmt.egg-info/scm_version.json's tag field 0.19.0 ✅ Exists after installing PyGMT. Out of our control
    TODO comments 0.19.0 ✅
    PyPI 0.19.0 ✅
    TestPyPI 0.20.0.dev60 ✅
    conda-forge 0.19.0 ✅
    version field on Zenodo v0.19.0 ❓

    Based on the above observations, I suggest:

  3. pinned this issue on Aug 9, 2026
  4. seisman commented on Aug 13, 2026

    @seisman
    Member

    Ping @GenericMappingTools/pygmt-maintainers for comments on the proposed changes.

  5. weiji14 commented on Aug 13, 2026

    @weiji14
    Member
    • Use 0.19.0 in pygmt.__version__
    • Use 0.19.0 in deprecation messages[ ]
    • Use 0.19.0 in "Minimum Supported Version" [Because the column title is "PyGMT version"]

    Ok for these ones. I checked a few other libraries (numpy, pandas, xarray, rioxarray) and their __version__ method doesn't return the v prefix.

    • Use 0.19.0 in Zenodo version field

    Ok for this too, I see at https://blog.zenodo.org/2017/11/02/version-field/ that they "strongly suggest that [you] use semantic versioning for machine-readability" as @yvonnefroehlich mentioned above. But do we keep the v in the zip file name? Also, do we want to backport the v prefix removal for old Zenodo versions, or just v0.20.0 going forward?

  6. seisman commented on Aug 14, 2026

    @seisman
    Member

    But do we keep the v in the zip file name?

    The ZIP file downloaded from GitHub Released has a file name like pygmt-0.19.0.zip, and we renamed it to pygmt-v0.19.0.zip manually before uploading to Zenodo. I think we should not add v to the ZIP file.

    Also, do we want to backport the v prefix removal for old Zenodo versions, or just v0.20.0 going forward?

    I'm OK with either. It would good to fix all records.

  7. added
    help wantedHelping hands are appreciated
    maintenanceBoring but important stuff for the core devs
    and removed
    discussionsNeed more discussion before taking further actions
    on Aug 14, 2026
  8. seisman commented on Aug 14, 2026

    @seisman
    Member

    Better to work on this issue after #4824.

  9. seisman commented on Aug 22, 2026

    @seisman
    Member

    Also, do we want to backport the v prefix removal for old Zenodo versions, or just v0.20.0 going forward?

    I'm OK with either. It would good to fix all records.

    I've uploaded the version field for all Zenodo records. Closing.

  10. unpinned this issue on Aug 22, 2026
  11. yvonnefroehlich commented on Aug 22, 2026

    @yvonnefroehlich
    MemberAuthor

    Also, do we want to backport the v prefix removal for old Zenodo versions, or just v0.20.0 going forward?

    I'm OK with either. It would good to fix all records.

    I've uploaded the version field for all Zenodo records. Closing.

    Should we also update the titles of the ResearchGate uploads and maybe of the announcements on the GMT forum.

  12. seisman commented on Aug 22, 2026

    @seisman
    Member

    I don't think it's worth the time

  13. yvonnefroehlich commented on Aug 24, 2026

    @yvonnefroehlich
    MemberAuthor

    It's probably not (easy) possible to change the text shown on the badges:

    Image

    Also the GMT repo has the leading "v" in the badges text:

    Image
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    maintenanceBoring but important stuff for the core devs

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions