Opened 15 years ago
Closed 9 years ago
#2915 enhancement closed fixed (fixed)
Provide way of incrementing patch number with date-based versioning
Reported by: | Jonathan Lange | Owned by: | therve |
---|---|---|---|
Priority: | low | Milestone: | totally automated release infrastructure |
Component: | release management | Keywords: | |
Cc: | Jean-Paul Calderone | Branch: |
branches/auto-version-2915-3
branch-diff, diff-cov, branch-cov, buildbot |
Author: | therve |
Description
Currently we do date-based versioning (i.e. YEAR.INCREMENT), but our version objects have fields for point-releases (X.Y.Z). Right now, 'Z' is always 0.
One day we might want it to be non-zero.
Change History (21)
comment:1 Changed 14 years ago by
Cc: | Jean-Paul Calderone added |
---|
comment:2 Changed 14 years ago by
It's definitely a poor description.
I think it's meant to refer to t.python._releases.getNextVersion
(pasted below), which quite clearly doesn't support patch numbers.
How did we increment the patch number in the 8.0.1 release?
def getNextVersion(version, now=None): """ Calculate the version number for a new release of Twisted based on the previous version number. @param version: The previous version number. @param now: (optional) The current date. """ # XXX: This has no way of incrementing the patch number. Currently, we # don't need it. See bug 2915. Jonathan Lange, 2007-11-20. if now is None: now = date.today() major = now.year - VERSION_OFFSET if major != version.major: minor = 0 else: minor = version.minor + 1 return Version(version.package, major, minor, 0)
comment:3 Changed 14 years ago by
Thanks, that clears things up. Maybe radix can comment on how 8.0.1 was produced.
comment:4 Changed 14 years ago by
We haven't even used getNextVersion yet. I just call the function that takes a version number directly.
comment:5 Changed 14 years ago by
Are we planning to call getNextVersion
at some point in the future?
comment:7 Changed 14 years ago by
Okay. So presumably getNextVersion
needs to have two different behaviors. One behavior is that it increments the major.minor
portion of a version in an appropriate manner, setting patch
to 0. The other is that it leaves major.minor
alone and increments patch
. The former behavior is for new releases (ie, the first release of a new branch of trunk). The latter is for subsequent releases of such branches. Can it tell what is going on by itself? Does it need a new parameter? Should there just be two functions?
comment:8 Changed 14 years ago by
I'd go for two different methods, possibly renaming the pair to incrementRelease
and incrementPatch
or something like that.
My working assumption is that the hypothetical automated release tool probably needs to take an argument as to whether a release is a bugfix release or not.
comment:9 Changed 11 years ago by
Owner: | radix deleted |
---|
comment:10 Changed 11 years ago by
Milestone: | → regular-releases |
---|
comment:11 Changed 10 years ago by
Owner: | set to therve |
---|
comment:12 Changed 10 years ago by
Author: | → therve |
---|---|
Branch: | → branches/auto-version-2915 |
(In [36614]) Branching to 'auto-version-2915'
comment:13 Changed 9 years ago by
Branch: | branches/auto-version-2915 → branches/auto-version-2915-2 |
---|
(In [36727]) Branching to 'auto-version-2915-2'
comment:14 Changed 9 years ago by
Keywords: | review added |
---|---|
Owner: | therve deleted |
The branch attached changes the way change-versions works: instead of passing the version, it takes 2 flags, prerelease and patch, which choose automatically the new version. Most of the changes are in getNextVersion, then ChangeVersionsScript and changeAllProjectVersions. I also removed updateTwistedVersionInformation which was not used anywhere.
getNextVersion code is fairly ugly, but the tests cover it properly, and match the use cases I have when doing releases.
Sorry for the formatting changes, I got a little bit carried away.
comment:16 Changed 9 years ago by
I also think this would be less ugly moved into two functions rather than writing getNextVersion(version, False, False, now)
.
Is there a reason you preferred one?
comment:17 Changed 9 years ago by
Well there are actually 3 versions, considering the prerelease bit, which overlaps with each other, so I don't think having 2 functions would really improve things.
comment:18 Changed 9 years ago by
Owner: | set to therve |
---|
- From twistedchecker:
ChangeVersionsScriptOptions
has no docstring. getNextVersion
has missing descriptions of a couple of arguments.- The code would be clearer if keyword arguments were used for
patch
andprerelease
.
Otherwise looks good. Please address the above and then merge.
comment:19 Changed 9 years ago by
Keywords: | review removed |
---|
comment:20 Changed 9 years ago by
Branch: | branches/auto-version-2915-2 → branches/auto-version-2915-3 |
---|
(In [37081]) Branching to 'auto-version-2915-3'
comment:21 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
We very recently did 8.0.1. I suppose that means we managed to make it non-zero. Does that mean this ticket is resolved? I don't think I quite understand the description.