Next Release stable release of GMT?

[ES-Solar]

I’d like to initiate a discussion about planning the next stable release of GMT — and, more broadly, about whether we should define clearer release criteria going forward.

Rather than deciding on a case-by-case basis, should we establish a more explicit framework? For example, we could choose to:

• Follow a roughly time-based schedule
  or
• Trigger releases based on clearly defined milestones (e.g., significant bug fixes, major feature additions, dependency
  changes)
  or
• Adopt a hybrid approach that balances both predictability and flexibility.

It’s also important to consider the broader ecosystem. How should stable releases be coordinated with related projects such as PyGMT and GMT.jl? Should downstream readiness be part of our release criteria?

Establishing a shared understanding of these principles could help us balance ongoing improvements with the need to provide stability and predictability for users.

Best regards,
Solar Smith

[joa-quim]

I do agree that we have accumulated sufficient new stuff for a release.

And with that sufficient I reiterate what I mentioned in the meetings. There is no point is setting a regular release scheduling when we have no guaranties to have enough changes to justify them. Having said this, I have nothing against some rules based on numbers to decide new releases, but I see this as a minor issue.

Regarding the wrappers, as long as nothing breaks them and that should not happen, at least without a thoroughly discussion, that is not a concern either. The worst it can happen here is that some new features are not implemented by them at the time of a release.

[Esteban82]

I don’t have a strong opinion on this matter. However, I would lean toward having periodic releases — as Joaquim mentioned — provided that there are enough accumulated changes to justify them.

[seisman]

The PyGMT project is under active development. Minor releases follow a quarterly schedule; for example, v0.18.0 was scheduled to be released in December 2025, and v0.19.0 is scheduled for March 2026. Patch releases, however, are issued as needed.

[ES-Solar]

Since there are already sufficient changes to justify an update then what do you think about the timing? Would we want to coincide with the next PyGMT update in March, or target the summer, for roughly 12-months since GMT 6.6.0 or some time in between?

Since PyGMT is going to be based on GMT 6.6, is it confusing to have GMT 6.7 come out just as PyGMT is getting updated?

[seisman]

Since PyGMT is going to be based on GMT 6.6, is it confusing to have GMT 6.7 come out just as PyGMT is getting updated?

PyGMT supports GMT 6.5, 6.6, and GMT dev version (i.e., the upcoming 6.7), so releasing GMT 6.7 won't affect PyGMT.

[ES-Solar]

I'm not sure what is involved in doing a release. Would March 30 be a good target date for releasing GMT 6.7?

[joa-quim]

Nope, that would not be good to me. I'll be absent during the Easter week and I need to solve an issue with the blas lib on Windows. My local tests are failing whenever it is used. Second half o April should be good though.

[ES-Solar]

Actually the 2nd half of April time frame is better for my schedule as well.

[ES-Solar]

I've the copied remote gmt datasets and software to an AWS S3 bucket. We are no longer(as of 6.6.0) putting the gmt release tarballs/installation files on the gmt mirrors. Should I not retain the older release tarballs, etc., from the mirrors in the AWS S3 bucket because we are moving away from that mode of distribution, or should I maintain those files in the new context in order to support legacy access patterns to the older versions?

[joa-quim]

The distribution mode has been, for a long time, based on Github releases, where we can find tarballs from GMT 4.5.18. I think anyone who will want to dig deeper in the GMT history will have to dive in the Github history.