Ticket #2915 enhancement closed fixed

Opened 6 years ago

Last modified 14 months ago

Provide way of incrementing patch number with date-based versioning

Reported by: jml Owned by: therve
Priority: low Milestone: totally automated release infrastructure
Component: release management Keywords:
Cc: exarkun Branch: branches/auto-version-2915-3
(diff, github, buildbot, log)
Author: therve Launchpad Bug:


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


Changed 6 years ago by exarkun

  • cc exarkun 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.


Changed 6 years ago by jml

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
        minor = version.minor + 1
    return Version(version.package, major, minor, 0)


Changed 6 years ago by exarkun

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


Changed 6 years ago by radix

We haven't even used getNextVersion yet. I just call the function that takes a version number directly.


Changed 6 years ago by exarkun

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


Changed 6 years ago by radix

Maybe once it provides a useful result :-)


Changed 6 years ago by exarkun

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?


Changed 6 years ago by jml

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.


Changed 3 years ago by <automation>

  • owner radix deleted


Changed 2 years ago by thijs

  • milestone set to regular-releases


Changed 16 months ago by therve

  • owner set to therve


Changed 16 months ago by therve

  • branch set to branches/auto-version-2915
  • branch_author set to therve

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


Changed 16 months ago by therve

  • branch changed from branches/auto-version-2915 to branches/auto-version-2915-2

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


Changed 16 months ago by therve

  • owner therve deleted
  • keywords review added

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.


Changed 16 months ago by glyph

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


Changed 15 months ago by Julian

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?


Changed 15 months 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.


Changed 14 months 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.


Changed 14 months ago by tom.prince

  • keywords review removed


Changed 14 months ago by therve

  • branch changed from branches/auto-version-2915-2 to branches/auto-version-2915-3

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


Changed 14 months ago by therve

  • status changed from new to closed
  • resolution set to fixed

(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.