Improving testing of release process

[tim-schilling]

I propose we allow suffixing the version number from an environment variable. This would then be utilized in our test release process to build the package with a unique version number.

The new action would run on the following events:

• A tag is pushed (same as today)
• Once a month
• A workflow_dispatch with a unique iteration value

There is more information on how this would be implemented here: https://github.com/django-commons/best-practices/blob/main/docs/releases.md

[devatbosch]

Hi @tim-schilling , I would like to work on this issue if none are working on it.
If so Could you plz hint me on the end-result/expectation to fix this issue...

[tim-schilling]

Hi @devatbosch, this is currently under discussion, so I'm not sure we'll implement anything for it.

However, if we do, I suspect the solution will be similar to https://github.com/django-commons/best-practices/blob/main/docs/releases.md#testing-releases and how that repo does it. Check the pyproject.toml file, the project's topmost __init__.py file and the test_release.yml GitHub action.

[devatbosch]

Sure @tim-schilling , will check on it.

Also, it would be pretty helpful if I can have some issue assigned to work upon, that you are intending to fix As a part of your upcoming release or deployment

Thank you!

[tim-schilling]

I'm not quite sure what you're looking for. Can you elaborate please?

[devatbosch]

@tim-schilling Yes, like any minor issue that you are currently facing in the repo. Like a bugfix/ correcting any segment of code since I want to get started with solving some minor issues and eventually try to level-up to solve/fix issues of greater complexity...

[tim-schilling]

@devatbosch please see any issues that are marked as "newcomer friendly", but are not marked as "djangonaut space".