This patch fixes the below bug by properly checking the old and new
version specifiers:
It seems that packaging fixed its SpecifierSet class' 'contains'
method recently which brought out a bug in validator:
When checking minimum versions we get a false negative [1] result due
to comparing '<str>' in '<SpecifierSet>', like '2.1.0' version string
(from old '>2.1.0' specifier) in '>2.1.0' (new) specifier, which should
be equal, but clearly version 2.1.0 is not in range >2.1.0, hence
the comparison gives back an error.
[1] Changed supported versions for dependency pyparsing from >2.1.0 to >2.1.0 without at least incrementing minor number
Change-Id: Iac1691714eaa8f5c236ed4c79b8ea7be92b8fcd9
It seems that packaging fixed its SpecifierSet class' 'contains'
method recently which brought out a bug in validator:
When checking minimum versions we get a false negative [1] result due
to comparing '<str>' in '<SpecifierSet>', like '2.1.0' version string
(from old '>2.1.0' specifier) in '>2.1.0' (new) specifier, which should
be equal, but clearly version 2.1.0 is not in range >2.1.0, hence
the comparison gives back an error.
[1] Changed supported versions for dependency pyparsing from >2.1.0 to >2.1.0 without at least incrementing minor number
Change-Id: Ib4984f2114f738451eb66cee5c47c4d271307da6
new-release command fails for cycle 'independent' projects with:
KeyError: '_independent'
as there is no such 'series' key when we load series_status_data for
checking release-id of the used series. Since this is needed only
for <series>-eol and <series>-eol checking, let's skip these checks
in case of independent series.
Change-Id: Id12b15af4e9507307b0e562648214b46c5c53aaa
Before the 'Unmaintained' phase of series was introduced all tags had
to be applied on master or stable branches. Now it is also possible
that am *-eol tag is applied on an unmaintained branch.
Change-Id: I767b1e80c594a84efe5f4874e9140d3ddc0347da
Validator originally checked for <series>-{eol,eom,em,last} tags.
Since we are using branch IDs since Antelope, the validator has to
accept for example 2023.1-eom, 2023.1-eol and 2023.1-last tags instead
of antelope-<..> tags.
Change-Id: I584c34a533db25a29206606d81d95ad2daa7779c
Originally when running 'new-release' command with 'eol', it checks for
stable/<series> branch only and sets HEAD of master if that does not
exist. But from now on, we have to be able to tag <series>-eol on HEAD
of unmaintained/<series> branch as well.
This patch:
- extends the check for unmaintained/<series> branch, so that its HEAD
will be used at <series>-eol tagging
- adds a check for <series>-eom tag so that the command will refuse to
create a release (with version numbers) after an EOM tag
- adds a fix to match complete <series>-eol tag when comparing with
latest version (this eliminates a bug, when the latest version is
a previous series' EOL tag, e.g. when EO{M,L}'ing tagless repos)
- handles the new type of <branch_id>-eom and <branch_id>-eol tags
(for example 2023.1-eol)
Change-Id: Id7e003b8070796cc99516a28752f94eaca62af61
We have the --type argument, where we can list which type of
deliverables we want to be listed, but we don't have the opposite
approach where we list the types that we DON'T want to be listed.
This patch introduces the --except-type argument with wich we can
list the deliverables with excluding some types, for example:
$ list-deliverables --series epoxy --except-type tempest-plugin
The above command lists all deliverables from 2025.1 Epoxy series
that aren't tempest-plugins.
Change-Id: If00115d3e7de055da2bd7a2dcd08298f70bd5989
We no longer have branches in extended maintenance state, these have
been switched to Unmaintained (eom). So we need to check for the latter
state when listing branches that could be deleted since the are EOLed.
Add oslo.utils to requirements since it is now needed by the
tools/delete_stable_branch.py script.
Change-Id: Ib948befa6f2706dc5dc50009b021af3a1bb389a8
We actually do need validation of tags being pushed for series that are
in the extended maintenance or now "Unmaintained" state in order to
avoid wrong hashes or duplicate tags being applied.
Change-Id: Idb110d94c11371ab9d519a428eaf28a0b5d61cd5
To be able to list all deliverables of a series that are tagged with
End of Maintenance, <series>-eom tag.
Change-Id: Ic1b23b45757e6ef1c250569c9e7337f8e7de39da
'<series>-last' tag is used to tag Tempest and its plugins to
work as last tag for EM release. Now with Unmaintained release
model, we need to allow this tag for Unmaintianed release also.
It will help Unmaintained branches to be tested with a compatible
version of Tempest and its plugin.
Change-Id: I7f58ad4570aead3b73bfab5c47cd29fa7a0a1700
Deliverables with model="untagged" or stable-branch-type="tagless"
don't have any series that needs to start with .0, so skip the
corresponding validation for them.
Change-Id: I8bd946eabf5f85dc003acca6188427a16396c8a6
When we tag a branch with <series>-eom we also need a new branch to cut
from there called unmaintained/<series>.
Change-Id: I3b746057a9c9443e23de7440833781329fe2b9cc
With the new TC resolution the community replaces Extended Maintenance
with Unmaintained status [1].
This patch introduces the new <series>-eom tag option for the
new-release command. The tag applies at the tip of the given
stable/<series> branch and the new unmaintained/<series> branch can be
cut from that tag.
[1] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html
Change-Id: Ie67da6f4857f0d438733799bf40f8ece66f67d32
With the new TC resolution the community replaces Extended Maintenance
with Unmaintained status [1]. To accomodate this, validator needs to be
extended to accept <series>-eom tags that applies at the tip of the
given stable/<series> branch and the new unmaintained/<series> branch
will be cut from that tag.
[1] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html
Change-Id: I606ba5e5f8fd783d6c3f83356ded27a46e8bac56
list unbranched deliverables is not designed to work with new release
id.
These changes add a command to allow to retrieve series id from a shell
script by passing the name of the series.
This new command is called by the list unbranched deliverables to check
if the corresponding stable branch exists (based on the release id).
Change-Id: I102b90c5221e57dd5697e2e81aa7edb8615ce445
Changes to tox in the past year have rendered the PBR-specific
tweaks in get_sdist_name invalid, since calling tox from within tox
now creates testenv directories relative to the parent tox's working
directory rather than the child's. While we're here, turn on more
verbose logging in the tox invocation, and fix the subprocess
routine to not discard the command's output.
Change-Id: I35fb5dde9ec400397ed21035d57c3efb872d8e58
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This results a false warning message now when
validating bobcat releases [2], as the validator searches for
stable/antelope instead of stable/2023.1 stable branch.
This patch fixes the validate_series_open validator to use release_id
for the branch name, where that exists. Besides, the patch also
refactors the release-id fetching and ensures that the release_id is
always returened as string and the series name is used if there is no
release_id for the given series.
[1] https://governance.openstack.org/tc/reference/release-naming.html
[2] validate_series_open: There is no stable/antelope branch defined in deliverables/antelope/<x>.yaml. Is the bobcat series open?
Change-Id: I71eae27f124473699c22dac0b0eb2b0b1d44b4da
Currently we're reverse sorting with a simple sort, this sadly puts
newer released (antalope, bobcat) at the end of the list. Add a
key function that has context around our release names and release ids
to sort "2024.1/cantaloupe"[1] at the top.
[1] As of now the c name isn't selected cantaloupe is my placeholder
Change-Id: I4b021d99bd4ecc232838a3639dd8d5ef075e1a24
The new way of packaging a python project is via build package. This
patch replaces the old setup.py style sdist and wheel build.
Change-Id: I67cbdfdfd9ed334e742ff4def21c59cd8a8de24c
hacking 6.0.0 release contains flake8 5.0.4, which started to show the
following error:
./openstack_releases/versionutils.py:54:14: E275 missing whitespace after keyword
yield('Version %s looks like a pre-release and the release '
This patch adds a whitespace after the 'yield' keyword to make the pep8
job pass.
Change-Id: I433ccb6a31cc450a666673374b78dcc1fea1bb7b
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This was not handled in the propose-final-releases command as
it still uses the release name. This patch fixes this by reading the
'release-id' field from series_status.yaml and if present then uses it
as stable/<release-id> for the branch creation.
[1] https://governance.openstack.org/tc/reference/release-naming.html
Change-Id: Ie8ba3e9bfa01148e93f5920050703e998248db11
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This was not handled in check_branch_sha method
in validate.py, as the method still searches stable/$series.
This patch fixes this by reading the 'release-id' field from
series_status.yaml if present and uses it as stable/<release-id>
for the branch search.
[1] https://governance.openstack.org/tc/reference/release-naming.html
Change-Id: I014b1d6dc561be4db0fc8faa85fb3133e851acfc
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This was not handled in the list-deliverables command as it
still uses the release name. This patch fixes this by reading the
'release-id' field from series_status.yaml and if present then uses it
as stable/<release-id> for the branch creation.
[1] https://governance.openstack.org/tc/reference/release-naming.html
Change-Id: Id6a03024fa2268ba233189abfe48556d3530daef
Independent projects do not have "stable" branches, so the
new_release script will fail.
Set version to master and change it accordingly only if it's not
and independent project.
Change-Id: I9ba7f251d64e2bfca5c262acf9b20dc3da23fc87
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This was not accepted in the validator command.
Previously the validator was fixed for 'std' and 'std-with-versions'
branching typed deliverables, but missed the 'tagless' deliverables
case. This patch fixes this by accepting the new branch naming style,
stable/<release-id>, for tagless deliverables, too.
[1] https://governance.openstack.org/tc/reference/release-naming.html
Change-Id: I6ba51454213e095e6b76e0813dab3ce44b1457ba
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This was not handled in the new-release command as it
still uses the release name. This patch fixes this by reading the
'release-id' field from series_status.yaml and if present then uses it
as stable/<release-id> for the branch creation.
[1] https://governance.openstack.org/tc/reference/release-naming.html
Change-Id: Ic9888b74b398d14f2a1dc5b6d30bca5f23493b5b
With the new release identification / naming schema [1] (like:
2023.1 Antelope) new stable branch naming was introduced (like:
stable/2023.1). This was not handled in the propose-library-branches
command as it still used the release name. This patch fixes this by
reading the 'release-id' field from series_status.yaml and if
present then uses it as stable/<release-id> for the branch creation.
[1] https://governance.openstack.org/tc/reference/release-naming.html
Change-Id: Ie87862669fb965729e23a9374c34b1ba2e71b445
For projects that has branch type 'std-with-versions' (like ironic,
because they cut bugfix/<MAJOR>.<MINOR> bugfix branches) the new stable
branch name style (like stable/2023.1) does not pass validator. This
patch extends the validator to accept these branch names, too.
Change-Id: If597684b1a4ea741707ee786e8e01e9e8f3d2cb4
The new release identification / naming schema [1] (like:
2023.1 Antelope) broke the redirection rules for branch specific upper
constraint files as the stable branch names are from now on based on
the new release identification (like: stable/2023.1).
This patch fixes the redirections by introducing the release ID field
to series status, to translate a release name to 'stable/<release-id>'
where this ID exists.
[1] https://governance.openstack.org/tc/reference/release-naming.html
Change-Id: Iab885d4e36f64903b323e16c74d8315c759584de
This fix aim to solve issues with the new naming convention related to
SLURP releases.
Without that our validation will fail to validate stable branches named
like `stable/2023.1`.
Change-Id: Ic45d4a13f63846e5b60bde800492da7c851addf8
This patch adds to the Releases page template the possibility to
indicate whether a release is a SLURP release.
Change-Id: Ie0dcddfe271e8fd77a6d40fa54c8ef2ee6914b78
Validation is not needed for a series as soon as it reaches the
Extended Maintenance state as there won't be any releases from such
branches. This patch updates the set of closed series to avoid
unnecessary validation.
Change-Id: I0f093865bab190273421d966c755434d0369e0a0
