| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
|
|
Python 2.7 has been EOL since January 2020.
Ubuntu oldoldlts (Focal Fossa, 20.04) has Python 3.8. Debian oldoldstable
(Buster, from 2019) has Python 3.7. RHEL 8 (from 2019) has Python 3.6.
It's easier than ever to install a modern Python using uv.
Given this, it seems like a fine idea to drop Python 2.7 support.
Even though the build is not tested on Python as old as 3.3, I left
comments stating that "3.3+" is the baseline Python version. However, it
might make sense to bump this to e.g., 3.10, the oldest Python 3 version
used during CI. Or, using uv or another method actually test on the oldest
Python interpreter that is desirable to support (uv goes back to Python 3.7
easily; in October 2025, the oldest supported Python interpreter version
will be 3.10)
Signed-off-by: Jeff Epler <jepler@gmail.com>
|
|
The Git hash is embedded in the version number. The hash is abbreviated by
Git. This commit changes the length of the Git hash abbreviation to a
fixed number, so that the length of the version string no longer varies
based on external factors (it can still vary, but will now be at least 10
characters).
This change is made because builds of the same MicroPython commit on
multiple machines were sometimes giving a version string with different
lengths, eg due to commits on other local branches having a clashing
abbreviated hash. This change may also help the code size report to be
more consistent, because it will less often be impacted by random changes
in the version string length, at the cost of always being a few bytes
longer.
Signed-off-by: Daniël van de Giessen <daniel@dvdgiessen.nl>
|
|
The former is deprecated.
Signed-off-by: Jos Verlinde <jos_verlinde@hotmail.com>
|
|
MICROPY_GIT_HASH was removed in 69e34b6b6bdf45bc1111777c46839a8b5fcb30bd
but it is useful for, and used by, third-party code to tell which hash of
MicroPython is used.
Signed-off-by: Damien George <damien@micropython.org>
|
|
See https://github.com/micropython/micropython/issues/12127 for details.
Previously at the point when a release is made, we update mpconfig.h
and set a git tag. i.e. the version increments at the release.
Now the version increments immediately after the release. The workflow is:
1. Final commit in the cycle updates mpconfig.h to set (X, Y, 0, 0) (i.e.
clear the pre-release state).
2. This commit is tagged "vX.Y.0".
3. First commit for the new cycle updates mpconfig.h to set (X, Y+1, 0, 1)
(i.e. increment the minor version, set the pre-release state).
4. This commit is tagged "vX.Y+1.0-preview".
The idea is that a nightly build is actually a "preview" of the _next_
release. i.e. any documentation describing the current release may not
actually match the nightly build. So we use "preview" as our semver
pre-release identifier.
Changes in this commit:
- Add MICROPY_VERSION_PRERELEASE to mpconfig.h to allow indicating that
this is not a release version.
- Remove unused MICROPY_VERSION integer.
- Append "-preview" to MICROPY_VERSION_STRING when the pre-release state
is set.
- Update py/makeversionhdr.py to no longer generate MICROPY_GIT_HASH.
- Remove the one place MICROPY_GIT_HASH was used (it can use
MICROPY_GIT_TAG instead).
- Update py/makeversionhdr.py to also understand
MICROPY_VERSION_PRERELEASE in mpconfig.h.
- Update py/makeversionhdr.py to convert the git-describe output into
semver-compatible "X.Y.Z-preview.N.gHASH".
- Update autobuild.sh to generate filenames using the new scheme.
- Update remove_old_firmware.py to match new scheme.
- Update mpremote's pyproject.toml to handle the "-preview" suffix in the
tag. setuptools_scm maps to this "rc0" to match PEP440.
- Fix docs heading where it incorrectly said "vvX.Y.Z" for release docs.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
|
Moving forward, tags in this repository will always have three components.
Signed-off-by: Damien George <damien@micropython.org>
|
|
This is handy when you are doing builds outside of the Git repository but
still want to record that information.
Signed-off-by: David Grayson <davidegrayson@gmail.com>
|
|
If a CMake-build is run with `make BUILD=/outside/path` then
makeversionheader.py is run with the CWD set to the build directory, which
means the git version lookup will fail and silently fall back to the
mpconfig.h mode (giving the wrong result).
This commit:
- Uses the location of makeversionheader.py to find the repo path.
- Allows overriding this path via --repo-path.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
|
|
Commit 64af916c111b61bce82c00f356a6b1cb81946d87 removed the version string
from docs/conf.py. py/mpconfig.h is a better place to get the version
from, so use that (when there is no git repository).
Signed-off-by: Damien George <damien@micropython.org>
|
|
This adds the --tags argument to the git describe command that is used
to define the MICROPY_GIT_TAG macro. This makes it match non-annotated
tags. This is useful for MicroPython derivatives that don't use
annotated tags.
Signed-off-by: David Lechner <david@pybricks.com>
|
|
This environment variable, if defined during the build process,
indicates a fixed time that should be used in place of "now" when
such a time is explicitely referenced.
This allows for reproducible builds of micropython.
See https://reproducible-builds.org/specs/source-date-epoch/
Signed-off-by: iTitou <moiandme@gmail.com>
|
|
Some downstream projects may use tags in their repositories for more than
just designating MicroPython releases. In those cases, the
makeversionhdr.py script would end up using a different tag than intended.
So tell `git describe` to only match tags that look like a MicroPython
version tag, such as `v1.12` or `v2.0`.
|
|
This is run with uncrustify 0.70.1, and black 19.10b0.
|
|
It's more robust to have the version defined statically in a header file,
rather than dynamically generating it via git using a git tag. In case
git doesn't exist, or a different source control tool is used, it's
important to still have the uPy version number available.
|
|
|
|
The line in docs/conf.py with the release/version number was recently
changed and this patch makes the makeversionhdr.py script work again.
|
|
This script may be called by Windows IDEs (e.g. Visual Studio) and be passed
paths with backslashes.
|
|
|
|
Addresses issue #1420.
|
|
These scripts should run under as wide a range of Python versions as
possible.
|
|
Addresses issue #1285.
|
|
Also rename py-version.h to mpversion.h for consistency with mpconfig.h.
|
