Opened 7 years ago

Closed 20 months ago

#2915 enhancement closed fixed (fixed)

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:

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

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

comment:3 Changed 6 years ago by exarkun

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

comment:4 Changed 6 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 6 years ago by exarkun

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

comment:6 Changed 6 years ago by radix

Maybe once it provides a useful result :-)

comment:7 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?

comment:8 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.

comment:9 Changed 4 years ago by <automation>

  • Owner radix deleted

comment:10 Changed 3 years ago by thijs

  • Milestone set to regular-releases

comment:11 Changed 21 months ago by therve

  • Owner set to therve

comment:12 Changed 21 months ago by therve

  • Author set to therve
  • Branch set to branches/auto-version-2915

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

comment:13 Changed 21 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'

comment:14 Changed 21 months 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 21 months ago by glyph

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

comment:16 Changed 20 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?

comment:17 Changed 20 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.

comment:18 Changed 20 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.

comment:19 Changed 20 months ago by tom.prince

  • Keywords review removed

comment:20 Changed 20 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'

comment:21 Changed 20 months ago by therve

  • Resolution set to fixed
  • Status changed from new to closed

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