[SERVER-27355] Avoid hard-coding 3.2 and 3.4 featureCompatibilityVersion in JS Created: 09/Dec/16  Updated: 06/Dec/22  Resolved: 05/Jan/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-30794 Make it easy to update jstests that s... Backlog
Assigned Teams:
Sharding
Participants:

 Description   

It would be great to be able to write something like 'latestFeatureCompatibilityVersion' and 'previousFeatureCompatibilityVersion', similar to 'latest' and 'last-stable' bin versions, instead of hard coding "3.2" and "3.4" everywhere in our JS code.

The code changes committed in SERVER-26828 should be considered in the solution. That code would benefit from a way to further determine whether the current release has a new feature compatibility version, because right now it's just a manual change between true and false.



 Comments   
Comment by Dianna Hohensee (Inactive) [ 05/Jan/17 ]

Closing as won't fix, because tests using a specific featureCompatibilityVersion should not be used for the next featureCompatibilityVersion.

Comment by Dianna Hohensee (Inactive) [ 13/Dec/16 ]

I'm not sure that SERVER-26165 is the right way to go about it. I think rather than removing any of the code, we should just make sure that it's flexible enough to be used when we need it for a new feature compatibility version.

I would suggest keeping all the checks, because it is still true that our v3.6 servers will be incompatible with the 3.2 featureCompatibilityVersion. The featureCompatibilityVersion must be 3.4, and checking is fine. Anything that is breaking, however, should be fixed.

Of course, I'm not familiar with query, so I may not be understanding exactly what cleanup they have in mind.

Comment by Max Hirschhorn [ 13/Dec/16 ]

Given that the upgrade/downgrade requirements for MongoDB 3.4 <~~> MongoDB 3.6 have yet to be detailed, I'm not sure how much we want to invest in making it easier to specify a featureCompatibiltyVersion in our testing infrastructure. We may reuse that machinery or create something else entirely. I'd suggest waiting on a decision that is informed from our planning process. Unfortunately, I don't think there's a way to escalate the question of what the planned work on SERVER-26165 is without having more information about planned MongoDB 3.6 projects. CC david.storch

Generated at Thu Feb 08 04:14:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.