Roadmap and expected Release Date for Apicurio V3

[syndimann]

Hey Guys,
thanks a lot for all the effort you put in Apicurio, the product is really great!

We are currently working with the milestone release of V3 and we were wondering if you have a roadmap and release date for the final version. We mainly use Apicurio via the API Endpoints and we ran into some issues (i.e. request payload has changed and is not fully reflected in the API documentation <base_url>/apis/registry/v3)

We are currently in the middle to decide whether we will start with Version 2 or go for the Version 3, so if you could help us on this topic and provide information that would be really great!

If you have already stated that information somewhere i am really sorry as i wasn't able to find that.

Thanks again for the great work!

Best
Kai

[EricWittmann]

Our intention is to have a version 3.0.0 released upstream in the next two to three weeks. From a Red Hat product perspective, we are targeting mid to late November for a supported version of 3.x to be released. If you are not a Red Hat customer, that's totally fine - I only include that information to give you a sense of the timing of the upstream roadmap. By the November timeframe we would expect upstream to be mature enough to cut a release that Red Hat will support.

Also - please if you have any specific feedback about 3.0, this would be a great time to share it. :)

[syndimann]

Hey @EricWittmann thanks a lot for the response, really appreciate it!
We are currently already using the milestone releases and are pretty happy with it. regarding feedback, we have some open topics which we are currently planning to implement ourselve, but maybe it would benefit the community in general, may be some of the topics are already implemented so sorry if that is the case:

UI (list-view):

• it would be really great to be able to default the list view to group view as a configurable item. currently it shows all items as default
• it would be really great to add the labels to the list view of the artifact (but i think the list endpoint currently does not propaget the labels only the detail endpoint does so, but i might be wrong)
• it would also be great as a further enhancement to have a more tree like view for the artifact list to expand an item to see the associated versions

UI (artifact detail view)

• it would be really great to see the associated labels of the different versions in the versions tab of the artifact details

Backend:

• We are using the mssql provider, we know this is community driven, but sometimes we face a connection lost for long running pods.

We hope this helps a little bit, we can also contribute (we already did with one pr for mssql) if that helps you.

Have a great day and thanks again for the great product!

[syndimann]

Hey @EricWittmann continuing the discussion here, would it be possible to only expose the labels in the versions and artifacts endpoints of the backend without going full circle for the frontend as well? at least for us this would be extremely helpful :)

talking about the following two endpoints:

• /apis/registry/v3/groups//artifacts//versions
• /apis/registry/v3/groups//artifacts/

thanks again for your response!

[EricWittmann]

Unbounded is still unbounded, whether they are used to display in the UI or not. I'm worried more about the API than I am the UI, actually. Although the UI is problematic as well.

But perhaps we could add the labels to the response if we have some documented limit. For example, limit the number of labels returned to something like 20. If you have more than that, it's OK but you won't get them back during search results. You will have to fetch them for a single artifact.

wdyt?

[syndimann]

Hey! Thanks for the reply and i totally agree with you on that topic, a documented limit would personally work great. so in our case we are just having around 3-5 labels per artifact version so that would work at least in our usecase and would be really helpful

[EricWittmann]

• Return Labels in search results/listings #5219
• [UI] Remember user's preferred state of Explore list view: Groups vs. Artifacts #5221

[EricWittmann]

If you feel strongly about a new Tree-like view, could you open a new GH issue for that? With an explanation of the functionality as you would like to see it?

[syndimann]

@EricWittmann sorry i need to jump on another topic and sorry for taking your valuable time. we saw that 3.0.0.M5 was released, thats really great!

https://github.com/Apicurio/apicurio-registry/releases/tag/3.0.0.M5

we currently rely on the binaries that are attached to the release, but for 3.0.0.M5 only the sources are available not the tar.gz file like for 3.0.0.M4

(e.g. apicurio-registry-app-3.0.0.M4-all.tar.gz)

is there an option to attached the tar.gz file as well? that would be really great and helpful! thanks a lot in advance

[EricWittmann]

Not sure why that file wasn't uploaded. Looking into it.

[EricWittmann]

Found the bug in our release workflow and fixed it. I'll see if the artifact can be uploaded after the fact...

[EricWittmann]

Sadly it seems that it is difficult to upload an asset to a release at a later time.

We should be doing a final version of 3.0.0 soon. As early as next week. Hopefully you can wait for that?

[syndimann]

That's all good, thanks a lot for the prompt response !

[EricWittmann]

Official releases of 3.x have been done now for a few weeks. We just released 3.0.3. Closing this discussion. :)

[syndimann]

Hey @EricWittmann sorry for the absence, thanks a lot for pushing the official release and all the effort, highly appreciated!

[EricWittmann]

No problem! I'm constantly way behind with my GitHub notifications. It's like a fire hose. 😂