[bug] Duplication of __openwisp_version__ leads to stale info

[nemesifier]

Describe the bug
The version number __openwisp_version__ defined in images/common/openwisp/__init__.py is hardcoded and never updated during the release process, causing it to become stale.

Currently, it shows version 25.10.0 while the latest release is 25.10.2 (I am going to fix this shortly).

This creates version duplication across the codebase.

Steps To Reproduce

1. Check the current version in images/common/openwisp/__init__.py
2. Compare it with the latest GitHub release tag
3. Observe that the version in __init__.py is outdated (e.g., 25.10.0 vs 25.10.2)

Expected behavior

I am not sure what's the best way to deal with this right now and I am open for suggestions.

We either need to automatically update this as part of the release process, or we need to make this dynamic and get the right version from the information we already have.

[Eeshu-Yadav]

To resolve the stale __openwisp_version__ definition we can dynamically pass OPENWISP_VERSION from the Makefile (the source of truth) into the Python scope.

Here is the proposed solution:

1. Update base-build in the Makefile to pass --build-arg OPENWISP_VERSION=$(OPENWISP_VERSION).
2. Update images/openwisp_base/Dockerfile to accept the ARG and assign it as an ENV variable (OPENWISP_VERSION=${OPENWISP_VERSION}).
3. In images/common/openwisp/__init__.py, dynamically fetch the version reading from the OS environment (os.environ.get("OPENWISP_VERSION", "unknown")).

This will eliminate the hardcoded version in Python and leverage the existing variable managed in the project root. Let me know if you are open to this approach and I can go ahead

[nemesifier]

@Eeshu-Yadav we need to take into account the changes being worked on in #555. Let's wait until that PR is merged.

[CodingWithSaksham]

Hi @nemesifier, I would like to work on this issue. My approach will be similar to the one suggested by @Eeshu-Yadav above, but one thing I am not sure about is how we would add a test case for this. Since this is technically a bug, we would likely need to add a test case for it (or would that be optional in this case?). Please let me know.

[openwisp-companion]

Hi @CodingWithSaksham 👋,

Thank you for your interest in contributing to OpenWISP! 🎉

According to our contributing guidelines, you don't need to wait to be assigned to start working on an issue.
We encourage you to:

1. Fork the repository and start working on your solution
2. Open a Pull Request (PR) as soon as possible - even as a draft if it's still in progress
3. Link your PR to this issue by including Fixes #570 in the PR description

Note: We suggest Fixes because this appears to be a bug. You can also use:

• Closes #570 for features/changes
• Fixes #570 for bugs
• Related to #570 for PRs that contribute but don't completely solve the issue

Once you open a PR that references this issue, you will be automatically assigned to it.

This approach helps us:

• See your progress and provide early feedback
• Avoid multiple contributors working on the same issue unknowingly
• Keep the contribution process moving smoothly

We look forward to your contribution! If you have any questions, feel free to ask in the PR or check our documentation.

Happy coding! 🚀

[openwisp-companion]

This issue has been automatically assigned to @CodingWithSaksham who opened PR #603 to address it. 🎯