fix(deps): cap untested future azure-functions SDK majors

Open
  • Is something wrong?
#646 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@bfs2021 is already working on this.

Since Oct 28, 2026.

  • #648 by @bfs2021 — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
azure, python
Domain
build-system, testing

Research direction

Review pyproject.toml and tests/test_sdk_compatibility_policy.py, then inspect the existing oldest/latest SDK wheel and host smoke matrix. Align the dependency markers and policy assertions with the supported SDK and host compatibility evidence, documenting any mismatch found. Done when the specified policy test passes, supported Python versions resolve the intended bounds, and existing wheel and host smoke checks remain coherent; an open pull request is already linked.

Written by the indexing model from the issue text.

Description

bug good first issue priority: medium size: XS

Context

The package declares azure-functions>=1.21.0 without an upper bound in pyproject.toml. A future 3.x release could be selected even though this repository has no 3.x certification. The existing compatibility-test policy (tests/test_sdk_compatibility_policy.py) also asserts the unbounded requirement.

OpenAPI already uses an interpreter-aware 1.x/2.x bound. This is a small package metadata and policy-test alignment task, not evidence that today's SDK is broken. Related: #613 (SDK compatibility testing).

Scope

  1. Use environment markers in [project].dependencies: 
    "azure-functions>=1.21.0,<2.0.0; python_version < '3.13'",
"azure-functions>=1.21.0,<3.0.0; python_version >= '3.13'",
  2. Add a brief explanation referencing the supported SDK/host compatibility evidence, without claiming that metadata alone certifies Azure execution.
  3. Update tests/test_sdk_compatibility_policy.py to check both requirements. Review the existing oldest/latest SDK wheel and host smoke matrix to keep its assertions coherent with the bound.
  4. Document any SDK-support mismatch found rather than silently weakening the tests.

Acceptance Checklist

  • Dependency markers parse and resolve correctly on Python 3.11 and 3.13 (CI provides interpreters; do not claim unrun local checks).
  • pytest -q tests/test_sdk_compatibility_policy.py passes.
  • Existing wheel-based and host smoke CI checks pass; no coverage lanes are removed.
  • No azure-functions 3.x can be selected by a fresh supported installation.
  • PR contains only this scoped metadata/test change; release notes follow the repository's release workflow.

Out of scope

  • Independently certifying a new SDK major, changing Python support, or restructuring CI.
  • Manually editing generated changelogs unless required by maintainers.

Contributor notes

Comment to request assignment before starting. Suggested PR title: fix(deps): cap azure-functions below untested 3.x. Include Closes #<issue number> in the PR body. No Azure subscription is required for the packaging/test edit.

Dominant language
Python
Stars
15
Forks
0
Avg merge
7h 53m
Merged PRs (30d)
90

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from yeongseon/azure-functions-logging-python

All issues in yeongseon/azure-functions-logging-python

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.