Skip to content

Finish release and fix release process#1607

Merged
mvdbeek merged 7 commits intogalaxyproject:masterfrom
bernt-matthias:start-0.75.37
Feb 5, 2026
Merged

Finish release and fix release process#1607
mvdbeek merged 7 commits intogalaxyproject:masterfrom
bernt-matthias:start-0.75.37

Conversation

@bernt-matthias
Copy link
Collaborator

@bernt-matthias bernt-matthias commented Feb 3, 2026

I released 0.75.36 manually by manually creating a tag and release via the GH interface, i.e. I did not follow the guidelines https://planemo.readthedocs.io/en/latest/developing.html .. but they seem not to work anyway :)

Currently the PR contains

  • a bump of the version that should have happened in the last release c9f543e
  • One minor fix in the makefile c05e661

The make open-docs step creates some minor white space changes which I also could commit here.

@nsoranzo
Copy link
Member

nsoranzo commented Feb 3, 2026

* a bump of the version that should have happened in the last release [c9f543e](https://github.com/galaxyproject/planemo/commit/c9f543ea56aa280131bafe91e8e60fb7aab614a9)

If you are going to do the release via pull request like in this case (which I find preferable), you need to use make commit-version instead of make release-local , otherwise the version gets bumped again to the next dev0 prerelease by new-version .

@bernt-matthias
Copy link
Collaborator Author

If you are going to do the release via pull request like in this case

I did not intend to do a release with this PR. My idea was just to finish what should have happened when I would have followed the guidelines.

which I find preferable

You mean a PR that bumps the version. And then creating the release via the GH interface? I guess we can do this (seems simpler). But then we should always do it this way (and document it), or?

Disadvantage would be that we would not have the ....dev0 version in the master branch (or we would need another PR).

@nsoranzo
Copy link
Member

nsoranzo commented Feb 3, 2026

If you are going to do the release via pull request like in this case

I did not intend to do a release with this PR. My idea was just to finish what should have happened when I would have followed the guidelines.

The PR title starts with "Finish release" :D

which I find preferable

You mean a PR that bumps the version. And then creating the release via the GH interface? I guess we can do this (seems simpler). But then we should always do it this way (and document it), or?

Yes, that would be my preference.

Disadvantage would be that we would not have the ....dev0 version in the master branch (or we would need another PR).

That's the same of the Galaxy release process (separate PRs to bump the final and pre-release versions).

@mvdbeek
Copy link
Member

mvdbeek commented Feb 3, 2026

That seems like a pain, it takes me a minute to cut a new release but if I do it this new way it's at least 2 PRs ...

@nsoranzo
Copy link
Member

nsoranzo commented Feb 3, 2026

@mvdbeek I find the Makefile workflow kinda brittle, but you are the one doing most releases, so I'm happy to keep it as it is. I can still do it half-manually if I need to.

Co-authored-by: Nicola Soranzo <nicola.soranzo@gmail.com>
@mvdbeek mvdbeek merged commit 5c38ff8 into galaxyproject:master Feb 5, 2026
15 checks passed
@bernt-matthias bernt-matthias deleted the start-0.75.37 branch February 5, 2026 18:30
@bernt-matthias
Copy link
Collaborator Author

Thanks @nsoranzo and @mvdbeek . I will try to create a release using the documented process.

@bernt-matthias
Copy link
Collaborator Author

Not there yet #1609 .. but close

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants