Handle pre-release versions in the doc actions

[greschd]

📝 Description of the feature

Currently, deploying a pre-release version (e.g. 0.3b1) fails, see e.g. this pipeline run: https://github.com/pyansys/pydpf-composites/actions/runs/4565823726/jobs/8057628442 [1]

When deploying the documentation for a pre-release version, we should consider that the logic needs to be somewhat different:

• The versions/stable should not be updated to point to the new pre-release
• The drop-down may contain the new version, but not marked as (stable); maybe marked as (pre-release) instead
• If this minor version already exists, it should probably be ignored. This is more of a rare edge case, since typically there should not be beta releases at the patch level (e.g an existing 0.2.1, and then a 0.2.2b1).

[1] Note that it's the "release to Github" step that fails, not docs. I think the special logic would mainly have to be in the docs, though.

💡 Steps for implementing the feature

No response

🔗 Useful links and references

No response

[greschd]

Ping @jorgepiloto @Revathyvenugopal162 @RobPasMue for visibility.

Note: this is not an urgent feature request. The PyPI publishing part of the release action works for pre-releases.

[RobPasMue]

Yes, this would definitely be a nice-to-have. Thanks for posting the issue @greschd!

[jorgepiloto]

Thanks for suggesting this, @greschd. The actions fail because no wheelhouse artifacts got generated. Just add the pyansys/actions/build-wheelhouse@v4 action.

Regarding multi-version for versions with suffix, this feature seems very interesting. I bet we can implement it in the actions.

[greschd]

Thanks for suggesting this, @greschd. The actions fail because no wheelhouse artifacts got generated. Just add the pyansys/actions/build-wheelhouse@v4 action.

@jorgepiloto do I understand it correctly that we'll also need to add this for the full release (not pre-release) pipeline to run successfully?

[jorgepiloto]

That's right, @greschd. The release-github@v4 action assumes that you have generated the following artifacts:

• documentation-html
• documentation-pdf
• -wheelhouse-.zip
• {library-name}-artifacts

[ludovicsteinbach]

Similarly it would be nice if it supported the "post" prefix in tags.

I've tried to release a version 1.0.0.post0, to fix minor issues in documentation, but that's currently blocked in the docs-deploy action

[jorgepiloto]

We had a short discussion about this issue. The logic for handling pre-releases would be as follow:

1. A pre-release (alpha, beta, rc, post, ...) is made.
2. The multi-version handles this version as usual.
3. If at some point, a stable release gets performed, any suffixed version for that version will no longer show, giving preference to the stable version.

[RobPasMue]

Yep let's go with that approach!

[jorgepiloto]

This issue is more complicated than what I expected. However, it is a desired feature.

I do not want to block new features that we want to implement in the incoming days. To protect the integrity of version 4.1, I am going to attach this issue to 4.2. This way, we can release 4.1 with simple features that are required, like #294.

[da1910]

As an unblocker for this, which remains a problem for us: can we just get the docs-deploy-stable action to ignore pre-release versions of packages? That doesn't address the issue with post releases, but does mean that at least three sets of perfectly valid semantic versioning tags will work as "expected"?

We need to make use of alpha and beta tags as our openapi packages are built during API development for testing purposes, and this issue blocks either our publishing of builds, or our use of the documentation deployment action. The former is unsustainable, the latter is inconvenient.

[RobPasMue]

@ansys/pyansys-core - we should work on this sooner rather than later. This has been going for too long. Many projects benefit from the usage of pre/post release tags - it'd be great to publish those docs. Pinging @greschd since we just spoke about it