Provide way of incrementing patch number with date-based versioning

[jml]

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.

[exarkun]

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.

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

[exarkun]

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

[radix]

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

[exarkun]

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

[radix]

Maybe once it provides a useful result :-)

[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?

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

[therve]

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

[therve]

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

[therve]

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.

[glyph]

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

[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?

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

[tom.prince]

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.

[therve]

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

[therve]

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