Skip to content

Commit

Permalink
Change next version to be a minor one as updating dependencies is a f…
Browse files Browse the repository at this point in the history
…eature not a bugfix.
  • Loading branch information
Michael Howitz committed Sep 7, 2023
1 parent 42f4a58 commit 98c94dc
Show file tree
Hide file tree
Showing 2 changed files with 3 additions and 3 deletions.
4 changes: 2 additions & 2 deletions CHANGES.rst
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,8 @@ The change log for the previous version, Zope 4, is at
https://github.com/zopefoundation/Zope/blob/4.x/CHANGES.rst


5.8.5 (unreleased)
------------------
5.9 (unreleased)
----------------

- Update to newest compatible versions of dependencies.

Expand Down
2 changes: 1 addition & 1 deletion setup.py
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ def _read_file(filename):
README = _read_file('README.rst')
CHANGES = _read_file('CHANGES.rst')

version = '5.8.5.dev0'
version = '5.9.dev0'

setup(
name='Zope',
Expand Down

4 comments on commit 98c94dc

@dataflake
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree with this choice. Updating dependencies is something I do for every single release. With your reasoning it means we will never have bugfix releases ever, just feature releases. That makes no sense.

@icemac
Copy link
Member

@icemac icemac commented on 98c94dc Sep 11, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I am counting correctly Zope 5.8.4 contained 3 new features and 4 bug fixes (+ version updates). So I would have expected, we call it a feature release. With my commit I wanted to prevent we stay on bugfix releases forever.
If we call dependencies updates not a feature (which might still be debateable), we can still decide to make the next release a bugfix, if it will just contain bug fixes.

@dataflake
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it looks like the mistake was made in the 5.8.4 release, which should have been 5.9.

I get your point about wanting to fix that mistake, but just raising the version number when 5.8.5 doesn't (yet?) contain any features is confusing.

I have added a note to the release docs at 00bc207. When looking at the change log the maintainer should think a second and decide what type of release it will be. I believe that would have prevented the issue for 5.8.4.

@mauritsvanrees
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

semver.org has this advice:

Question: What should I do if I update my own dependencies without changing the public API?
Answer: That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. We would usually expect additional code for the latter instance, in which case it’s obviously a minor level increment.

So the standard "update versions.cfg/constraints.txt to latest package versions" after a Zope release, would be fine for a bugfix release.

Please sign in to comment.