I don't see why we need to manually set the next versions since they can be calculated from the current ones. We can either fix that or use release sanity so we won't make the mistake I had to fix in attachment 526311 [details] [diff] [review].

See bug 575400 for the details why we decided to manually set next versions. I'd WONTFIX.

Could we then turn it into a release sanity bug? It makes sense to ignore the message if we want to bump to a non-sequential version.

(In reply to comment #2) > Could we then turn it into a release sanity bug? > It makes sense to ignore the message if we want to bump to a non-sequential > version. If you have a specific thing that you think release_sanity.py should be looking for, please file a bug with that information. In the future, an extension of the work done in bug 627308 is expected to make standard version bumps such as this one much less painful.

Would you be fine morphing this bug into a release_sanity bug? "release sanity should warn that nextAppVersion and nextMilestone are a dot release forward"?

wfm

Is this still valid in the rapid release world? I would note that the summary as worded "nextAppVersion and nextMilestone are a dot release forward" is confusing. AFAIK that is the expected state for release builds, except for major release which will be a full integer bigger. For beta builds, the milestone also doesn't change except for when we do a major release.

For most branches they don't need to set manually anymore: 30 releaseConfig['nextMilestone'] = releaseConfig['version'] Given that, I think we should WONTFIX this. Armen?