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


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 Jean-Paul Calderone

Cc: Jean-Paul Calderone added

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.

comment:2 Changed 14 years ago by Jonathan Lange

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 =
    major = now.year - VERSION_OFFSET
    if major != version.major:
        minor = 0
        minor = version.minor + 1
    return Version(version.package, major, minor, 0)

comment:3 Changed 14 years ago by Jean-Paul Calderone

Thanks, that clears things up. Maybe radix can comment on how 8.0.1 was produced.

comment:4 Changed 14 years ago by radix

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 Jean-Paul Calderone

Are we planning to call getNextVersion at some point in the future?

comment:6 Changed 14 years ago by radix

Maybe once it provides a useful result :-)

comment:7 Changed 14 years ago by Jean-Paul Calderone

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 Jonathan Lange

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 <automation>

Owner: radix deleted

comment:10 Changed 11 years ago by Thijs Triemstra

Milestone: regular-releases

comment:11 Changed 10 years ago by therve

Owner: set to therve

comment:12 Changed 10 years ago by therve

Author: therve
Branch: branches/auto-version-2915

(In [36614]) Branching to 'auto-version-2915'

comment:13 Changed 9 years ago by therve

Branch: branches/auto-version-2915branches/auto-version-2915-2

(In [36727]) Branching to 'auto-version-2915-2'

comment:14 Changed 9 years ago by therve

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:15 Changed 9 years ago by Glyph

I forced a build to make the reviewer's job easier.

comment:16 Changed 9 years ago by Julian Berman

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 therve

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 Tom Prince

Owner: set to therve
  1. From twistedchecker: ChangeVersionsScriptOptions has no docstring.
  2. getNextVersion has missing descriptions of a couple of arguments.
  3. The code would be clearer if keyword arguments were used for patch and prerelease.

Otherwise looks good. Please address the above and then merge.

comment:19 Changed 9 years ago by Tom Prince

Keywords: review removed

comment:20 Changed 9 years ago by therve

Branch: branches/auto-version-2915-2branches/auto-version-2915-3

(In [37081]) Branching to 'auto-version-2915-3'

comment:21 Changed 9 years ago by therve

Resolution: fixed
Status: newclosed

(In [37084]) Merge auto-version-2915-3

Author: therve Reviewer: tom.prince Fixes: #2915

Automatically pick the next version in the change-versions release script.

Note: See TracTickets for help on using tickets.