Change:
return deployments, nil } <ins> // ReplicaSetsByRevision sorts a list of ReplicaSet by revision, using their creation timestamp or name as a tie breaker. // By using the creation timestamp, this sorts from old to new replica sets. type ReplicaSetsByRevision []*apps.ReplicaSet func (o ReplicaSetsByRevision) Len() int      { return len(o) } func (o ReplicaSetsByRevision) Swap(i, j int) { o[i], o[j] = o[j], o[i] } func (o ReplicaSetsByRevision) Less(i, j int) bool { revision1, err1 := Revision(o[i]) revision2, err2 := Revision(o[j]) if err1 != nil || err2 != nil || revision1 == revision2 { return controller.ReplicaSetsByCreationTimestamp(o).Less(i, j) } return revision1 < revision2 } </ins>

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: when deployment controller cleans up old ReplicaSet, it sorts all old ReplicaSets by createTimeStamp and delete the oldest one, which may cause Deployment roll back to a wrong version. How to reproduce it (as minimally and precisely as possible): Suppose we set the revisionHistoryLimit of a Deployment to 3, and currently we have 3 Replicas: r1, r2, r3 (the createTimeStamp and Revision both are r3 r2 r1); if we upgrade and roll back 3 times continuously, there will be an expected case: upgrade: &nbsp; ReplicaSet will be: r4, r3, r2 &nbsp; createTimeStamp: r4 r3 r2 &nbsp; reversion: r4 r3 r2 rollback: should rollback to v3 &nbsp; ReplicaSet will be: r4, r3, r2 &nbsp; createTimeStamp: r4 r3 r2 &nbsp; reversion: r3 r4 r2 upgrade: &nbsp; ReplicaSet will be: r5, r4, r3 &nbsp; createTimeStamp: r5 r4 r3 &nbsp; reversion: r5 r3 r4 rollback: should rollback to v3 &nbsp; ReplicaSet will be: r4, r3, r2 &nbsp; createTimeStamp: r5 r4 r3 &nbsp; reversion: r3 r5 r4 upgrade: &nbsp; ReplicaSet will be: r6, r5, r4 &nbsp; createTimeStamp: r6 r5 r4 &nbsp; reversion: r6 r5 r4 rollback: should rollback to r3, but instead, we rollbacked to r5, and this may cause error. What you expected to happen: when deployment controller cleans up old ReplicaSet, it should sort old ReplicaSets by Revision
/sig api-machinery /sig apps
does this make sense to you? /assign /cc
?
/remove-sig api-machinery
This requirement makes sense. Unassign API machinery - SIG Apps should own this.
Issues go stale after 90d of inactivity. Mark the issue as fresh with .

Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details