[SERVER-35767] Organize upgrade-downgrade tests as generic or non-generic regarding feature compatibility version Created: 22/Jun/18  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Upgrade/Downgrade
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Dewal Gupta Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Unresolved Votes: 0
Labels: stm
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Server Tooling & Methods
Participants:

 Description   

Enforce a requirement to allow developers to specify whether or not test that use FCV are generic (should be kept from release to release) or non-generic (version specific).



 Comments   
Comment by Steven Vannelli [ 10/May/22 ]

Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions.

Comment by Maria van Keulen [ 19/Dec/19 ]

ian.whalen Sure. The benefit of this is to ease the Upgrade/Downgrade work of determining which tests are version-specific, and thus need to be removed in the following release, and which are generic, so should be kept.
We did do this to a degree with our existing testing in SERVER-33271, but it would be great to have an enforceable means of classifying these tests.

Comment by Ian Whalen (Inactive) [ 19/Dec/19 ]

maria.vankeulen as one of the people still on Server who might have context - can you help explain what the benefit is to doing this so we can figure out a priority in whether or not we do it?

Comment by Max Hirschhorn [ 29/Jun/18 ]

ian.whalen, my understanding of this being on the Storage team's backlog is because this ticket relates to Dewal's intern project.

Comment by Ian Whalen (Inactive) [ 29/Jun/18 ]

Putting on the TIG team to consider/prioritize for now because there isn't anything very Storage-specific about this.

Comment by Dewal Gupta [ 22/Jun/18 ]

Based on a conversation with max.hirschhorn and maria.vankeulen, one possible solution would be to use ESLint to parse for uses of setFeatureCompatibilityVersion. Also, "generic" and "non-generic" tags could be added in resmoke andĀ ESLint could be used to detect the presence of (or lack thereof) these tags.

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