Hi @rachelatmonday ,
Did the dev team give you an update on this?
Kind regards,
Hi @Pask,
The team is working on a fix that should be deployed in the next few days! I will post on this thread when it is live 
1 Like
@Pask it should be deployed now! Try it out when you get a chance and let us know if you have any issues.
2 Likes
Hi @rachelatmonday ,
Thank you so much for the feedback.
We’ve already updated our solution to start testing with the new APIs and I can confirm it everything seems to work fine on our end.
Thanks again for the help!
Kind regards,
2 Likes
@Pask we are glad this is working now!
Let us know if you have any other questions or issues!
Cheers,
Matias
1 Like
Thanks for the updates. I posted a question here regarding what the [ID!] datatype means compared to [Int]: Is the ID! data type alphanumeric?, since many of the IDs are changing to that. Any help would be appreciated.
1 Like
When can version 2023-10 be used in production applications? Should we hold off on using it in production until October, when it is officially released? Could there be breaking changes in 2023-10 between now and October? Thanks for all your helpful advice!
Hey @PluginGenie – you’re right, the version will not be stable until October 1st. We’re not planning any major changes but we can’t guarantee that we won’t make small tweaks.
Here’s my 2 cents:
Strike while the iron is hot and start reviewing and migrating any affected queries. However, keep that version on a separate branch (aka not production).
Between now and October, keep an eye on the API changelog in case we make any further changes.
Let me know if that helps!
2 Likes
@rachelatmonday - I recognize this may be a little late to the discussion and possibly just me, but the description of the rolling window of versions ( API Versioning ) seemed more confusing than it needed to be. I drew it out this way to help me better mentally capture the flow. Am I on target here?:
(NOTE: Not sure whether there will be a standing pattern of what the Default version as of 4/1/2024 - or whether each API Changelog and Release Notes will have to be watched)
Hi @marksmalley,
Thanks for the feedback! I would definitely agree with you. We’ve been adjusting that article to make it more clear but also understand that there’s a lot of information that can make it confusing. That said, your diagram is spot on!
Since this is our first version that contains so many breaking changes, we are providing devs extra time to migrate to the new version. Therefore, the default version if you send a request without a header will remain 2023-07 until January 1st, 2024.
After January 1st, we will resume the normal pattern of the most recent stable version being the default. That means 2024-01 will be the default starting January 1st, 2024, 2024-04 on April 1st, 2024, 2024-07 on July 1st, 2024 and so on 
Please let us know if you have any other questions!
Best,
Rachel
1 Like
The is helpful clarification, @rachelatmonday . Thank you. I’ve included the clarification here for completelness:
3 Likes
Perfect, that looks amazing! Thanks for sharing here as well - I am sure others would love to see it instead of just reading it 
2 Likes
Hi, I have a question regarding the date field. You can find more information about it in this post:
Any help would be appreciated. Thanks!
Hey friends! I collected all our API migration resources so far in one post. Check it out below!
Hello @rachelatmonday and @dipro !
Per Breaking change: `Text` field empty value for mirror, dependency, and connect boards columns my understanding is that the column_values will return empty results for a connect_boards column. However, I am testing 2023-10 and successfully return text for my connect_boards (even connections with multiple items):
{
boards(ids: 3390430078) {
items_page(limit: 25, cursor: null) {
cursor
items {
name
column_values {
column {
title
id
type
}
id
text
}
}
}
}
}
This is GREAT news - but it seems to be contrary to what the article is saying? Could it be that the connect_boards column will actually return text representation of the items (items’ names) that they are linked to?
I don’t want to depend on it if it will be ripped out later.
Thanks!
Hey Mark, will need to double check this with our R&D team and get back to you! Some folks are out of office so I might only get a response next week at some point.
Hey Mark, there’s a bug – the generic column_values object should return null values but is returning data at the moment. We’ll fix it soon.
You will need to use the BoardRelationValue fragment to get this data instead. Something like this:
{
boards(ids: 4580008782) {
items_page(limit: 25, cursor: null) {
cursor
items {
name
column_values {
column {
title
id
type
}
id
text
...on BoardRelationValue {
id
text
}
}
}
}
}
}
The reason behind this is that retrieving connected data is resource-intensive, so we only want to do it when the client explicitly asks for it (using this BoardRelationValue type).
NB: the migration guide originally mistakenly said you need to use the linked_items field to do this; you can actually just use the fragment above.
1 Like