Prepare the 1.1.0-pre0 release.

Review Request #3852 — Created May 9, 2016 and submitted

mateor
pants
3375
pants-reviews
gmalmquist, jsirois, molsen, stuhood

First release with new numbering scheme.

Releases from master are now labeled 1.1.M-preN.
Pants is building to patch number M and is N
zero-indexed releases towards that milestone.

The 1.0.0 is still the currently LTS release.
Versions under the 1.1.M-preN numbering scheme
are to be considered volatile in comparison.

  • Removed options that were to be deprecated in 0.0.83.

  • Bumped deprecation of preferred_jvm_distribution.
    It was to expire in .89, so bumped it to 1.1.1 for now.

Ran the unit tests and pre-commit tests.

Jenkins run is away (again): http://jenkins.pantsbuild.org/job/pantsbuild/job/pants/branch/PR-3375/1/

  • 0
  • 0
  • 1
  • 0
  • 1
Description From Last Updated
MA
  1. There were 2 instances in the commit log where a commit landed and was reverted in the next commit. This changelog
    does not include the original or the revert for those.

    I also now have a deprecation set as 1.1.0-pre6. I have not yet tested that our
    deprecation framework can understand that. I will check it out while this is being
    reviewed.

    1. I think its always safe, and less confusing, to eliminate commit/revert pairs that happen inside 1 release.  Its just changelog noise.
  2. 
      
MO
  1. 
      
  2. src/python/pants/CHANGELOG.rst (Diff revision 1)
     
     

    M would actually be the patch version here. I think its safe to say 1.1.0-preN for this message.

  3. 
      
ST
  1. Can you clarify where this will be merged? To master, presumably, followed by creation of the 1.1.x branch?

    1. I was intending to merge it to master and then call it a day. I am just following the available documentation.

  2. I don't expect that there will be 6 pre-releases of 1.1.0... if this is supposed to be extended to the next release, you'd probably want to mark it for 1.1.1 or something.

    1. Okay. But that means that whoever releases the 1.1.0 tag will now have to remove the deprecations, which will be the first time they are removed. Could increase the likelyhood that the 1.1.0 release has code that never ran in production, imo.

    2. No: because 1.1.1 is greater than 1.1.0.

    3. okay...version typo aside, I think my point stands.

      Any deprecation marked 1.1.1 will likely only be removed when someone updates the version.py to match that number. So if I mark this with a tag that stands for a LTS release (1.1.1 in your example) then that LTS release will likely remove those options for the very first time.

      I have marked it 1.1.1 with the presumption that you have thought about that and consider it a moot point. Will update when master goes green.

    4. Yea, I see what you mean now. Apologies.

      Perhaps what you wanted to do here was 1.1.1-pre0 or 1.2.0-pre0 then? So that the next releaser of those respective versions are forced to deal with this immediately upon cutting tagging those?

    5. Np :)

      My original thought was that I would bump it 6 "releases", with the understanding that we may have to update to the deprecation code so that it normalizes our new version names, i.e. understand that 1.1.1-pre0 deprecates all 1.1.0-preN, no matter if the N was released or not.

    6. My original thought was that I would bump it 6 "releases", with the understanding that we may have to update to the deprecation code so that it normalizes our new version names, i.e. understand that 1.1.1-pre0 deprecates all 1.1.0-preN, no matter if the N was released or not.

      That shouldn't be necessary. Semver is ordered: so 1.1.1-pre0 comes before 1.1.1-pre6, and I believe our tests confirm that.

  3. 
      
MA
JS
  1. Ship It!
  2. 
      
MA
  1. There was a conflict with the 1.0.0 cherry-picks. My commit message for the new CR was:

    The changelog is accurate in terms of releases but is not
    accurate in respect to master. The specific problem commit
    is 3ae0f77513f2da45b0348913d0417d829aaad86e in master.
    
    It was cherry-picked into the 1.0.0-rc3 and 1.0.0 releases.
    But commits that landed after it have never been included
    in a release.
    
    The changelog helper correctly identified it as within the range
    between the last commit and HEAD - the commit had been
    released but with a different SHA since it was cherry-picked
    into the new branch.
    
    IMO, the 1.0.0 and RCs should have maintained their own CHANGELOGs
    and the last release on master should have been 0.0.82.
    But others disagree and that ship has sailed.
    
    I simply removed the duplicate RB commit from the list and
    updated the CHANGELOG. This should not be a problem again
    until we make a 1.1.0 branch and perhaps the policies will be
    fleshed out by then.
    

    I published the docs locally and inspected the output.

    1. Well, actually I would have preferred to release 1.0.0 from master and then fork the 1.0.0 branch from there. But none of this is that big of a deal, in any case.

  2. 
      
MA
MA
Review request changed

Status: Closed (submitted)

Change Summary:

Thanks all. Submitted as: 0b6ebee69cf63630c0e8f2fb9ad341477c70c2d7

Loading...