v1.0.1 is out — and I'd like to hear how you're using openapi-generics

[bsayli]

Category: Announcements
Tags: release, v1.0.1, feedback, byoe, byoc

---

Hi everyone 👋

Quick update on where the platform stands and an honest ask for feedback.

---

📦 What just shipped

v1.0.1 was released on May 1, 2026 — a patch for the 1.0.x GA line.

• No contract changes
• No public API changes
• No generated client structure changes
• Fully compatible with v1.0.0

Focus: build hygiene, dependency alignment, release reproducibility. Spring Boot baseline → 3.5.14, OpenAPI Generator → 7.22.0.

Full notes: v1.0.1 Release

---

🧭 Where the 1.0.x line stands

Version	Date	What it brought
v0.8.x	Apr 4–5	First Maven Central publication
v0.9.0	Apr 12	BYOC + Spring Boot 4 support
v1.0.0	Apr 18	GA — explicit contract-first generation
v1.0.1	May 1	Build hygiene + dependency alignment

What this stabilizes:

• Default envelope — ServiceResponse<T>, ServiceResponse<Page<T>>
• BYOE — bring your own envelope (no migration needed)
• BYOC — reuse externally owned DTOs (no duplication)
• Spring Boot 3 and 4 — both validated end-to-end
• Template governance — upstream drift fails the build, not your client

The principle hasn't changed since Sep 2025:

Java contract is the authority. OpenAPI is a projection.

What changed is that the platform now actually delivers on it across the full pipeline.

---

💬 The honest part — I'd like to hear from you

openapi-generics has been on Maven Central for a few weeks. I can see it's being pulled into builds. What I can't see is who's using it, how, or what's painful.

So I'm asking directly. Even one or two sentences are useful.

If you're starting fresh (default envelope)

• Are ServiceResponse<T> and ServiceResponse<Page<T>> enough for your use cases?
• Does the built-in Page<T> fit your pagination needs, or do you have your own model?

If you brought your own envelope (BYOE)

• Was BYOE setup straightforward, or did you hit friction?
• Did the constraints (concrete class, single type parameter, single payload field) cause issues?
• Was the startup-time fail-fast validation helpful or annoying?

If you have a shared contract module (BYOC)

• Are you mapping shared DTOs across services? How does it work in practice?
• Did avoiding DTO duplication justify the BYOC setup overhead?

Cross-cutting questions

• Spring Boot version: 3.x or 4.x?
• Error model: RFC 9457 ProblemDetail (Pattern A) or envelope-based errors (Pattern B)?
• Template governance: Have you upgraded OpenAPI Generator versions? Did fail-fast behavior help?

There is no wrong answer. Critical feedback is more useful than positive — it shows me what's actually broken.

---

📨 How to share

• 💬 Reply here — easiest, lowest friction
• 🐛 Open an issue for concrete bugs
• 💡 Open an Idea for design suggestions
• 🔗 LinkedIn DM if you'd rather not share publicly

👍 If you're evaluating or using this in a company setup, even a simple reaction (👍) on this discussion is very helpful — it helps me understand real usage without requiring public details.

Anonymous or company-redacted feedback is completely fine. The goal is to learn, not to publish a customer list.

---

🧭 What this shapes

Real input affects:

• v1.1 priorities — additional generic shapes? Better diagnostics? More codegen targets?
• Documentation depth — which adoption paths need worked examples
• BYOC pattern expansion — what shared-contract setups do real teams have?

The roadmap is open. Real usage signals weigh more than abstract design.

---

🙏 Thank you

If you're building with this — even quietly, even just evaluating — thank you. Every bit of real-world signal helps the platform stay grounded in actual use rather than theoretical architecture.

— Barış

---

📦 Repository: https://github.com/blueprint-platform/openapi-generics
📚 Adoption Guides: https://blueprint-platform.github.io/openapi-generics/
🔗 Maven Central (Group): io.github.blueprint-platform