Create MR to remove from code (see !44866 (merged)), and arrange it to be merged sometime in %13.11
Create MR to add fields to 'removed items' section of the docs (see !45377 (merged))
Ping @gweaver so the removed fields notice can be added into the release post
Create an issue like this one for %14.6 and tag @gweaver. Ask him to set the milestone to %14.5 and the due date to the 16th of that month (some days before the release) - #334278 (closed)
@cablett@gweaver i opened an issue to track removal of a dast-specific field. should removal of deprecated fields take place in a single, coordinated, merge request?
I think so. I felt it kept everything in one place for customers who want to understand how our GraphQL fields are changing. We could always link issues and other MRs to it. WDYT? I feel like this is a good one for @gweaver to weigh in.
@cablett@philipcunningham It's fine if we use multiple issues / MRs so long as they are related to each other so when it comes time to write the release post updates, we can quickly see everything being deprecated / removed and ensure we don't miss adding anything to the public announcement.
@.luke it most likely should be assigned to an engineer. I'm not sure who will have availability once we kick-off 14.0 though so unless someone wants to volunteer now, I'll wait to schedule / coordinate with my EM once we get closer to 14.0.
@jlear@johnhope@cablett@digitalmoksha I've created a task list for all of the removals that have been communicated as being needed in 14.0. How can we best split up this work to make sure all of the items are successfully removed as part of the 14.0 release?
@gweaver Does it need splitting up? I did all the fields in one go in !44866 (diffs) for %13.6. I think one person could even split it up into several MRs themselves.
@cablett we can split it up however you / the engineers want. Feel free to update the description to break it into different chunks. I don't think we need to split it up across issues (unless they already exist), but it can be split across however many MRs you want -- which could help with boosting MR rates for the month
@jlear@gweaver I'm a little concerned that this issue is far down the list and so it might not get picked up in time. I'm happy to take it or you're free to tag another engineer. Happy either way.
@cablett we should be able to split this up and assign it to a few different engineers in Plan to be DRIs for each respective section. If you can split up the description, @jlear can help identify a few more engineers to help out!
@acroitor@mcelicalderonG - could you help @cablett out here with removals for deprecated fields? We'll want to get these wrapped up in the coming week so that they have time to make the cutoff before June 14.
cc @euko - This could be interesting for you as well, if you want to look at !44866 (diffs) as a reference from last time and take a try at opening an MR for removing some of these.
I don't think it really matters how they are split up.
just to clarify the 13.6 is the cutoff for removing deprecations ? or is it 13.7 ?
We want fields to be removed after at least six releases so I don't mind either way. I quite like removing on x.6x.0 because it keeps things simple. Beyond that I don't think it matters too much but others might have other opinions.
Right, I'll close mine (!63470 (closed)). One thing to note is that in order to remove those fields from the backend, frontend work will be required first, as discussed here and here.
PS: I see from the docs how we can release breaking changes on X.6 now, but still seems weird we can do that on a minor release. Is there an issue where that was discussed? I'd love to get some context on that.
@acroitor, it looks like SortEnum deprecation might have the same problem as timeframe deprecations, it is still used in the frontend at least here and here. This one at least won't require a backend fix first to support the new value as that is already correct.
@euko could you please help me confirm if these 4 values are still used in the frontend for the SortEnum type?:
updated_desc
updated_asc
created_desc
created_asc
The capitalized version should be used for all, instead:
That'd be awesome, @euko. Thanks! I'm sure I'd miss a place or two where the non capitalized version are used. I guess that if those changes make it to %14.0 and production we can actually remove those deprecated values from the backend
Thank you @euko, no problem! I'm actually unsure if we could remove this fields for the upcoming release even if the frontend removal changes made it to production, passing by canary in time. @donaldcook could you help us figure this out? We started a conversation in !63293 (comment 594786164) about other time related arguments that were still used by the frontend. I think the only remaining concern is if on premises installs have multi-deploy envs with canary or if that just happens on gitlab.com. If so, should we release frontend removals in %14.0 and API removal of these fields in v15.0?
I do not have the data about on-premise installs running on multiple servers, but it would not be unrealistic to think that there are such instances, running gitlab on multiple servers and doing rolling-deploys as well
But even if it has been deprecated for more than 6 releases, we shouldn't ship breaking changes to any minor release, right? That's why I figured 15.0 would be our next chance.
@mcelicalderonG did the removal of those extra fields moved to 14.6 now? I've created a similar issue for removing deprecated fields in 14.6 #334278 (closed) so we can mention the fields that did not make it in 14.0 there.
Alexandru Croitormarked the checklist item Create MR to remove from code (see !44866 (merged)), and arrange it to be merged sometime in %13.11 as completed
marked the checklist item Create MR to remove from code (see !44866 (merged)), and arrange it to be merged sometime in %13.11 as completed
Alexandru Croitormarked the checklist item Create MR to add fields to 'removed items' section of the docs (see !45377 (merged)) as completed
marked the checklist item Create MR to add fields to 'removed items' section of the docs (see !45377 (merged)) as completed
Alexandru Croitorchanged the descriptionCompare with previous version