blueprinter
blueprinter copied to clipboard
procore-oss
Plan for adding and deprecating new API versions
Is there an existing issue for this?
- [X] I have searched the existing issues
Is your feature request related to a problem? Please describe
As we work on adding a V2 API, we'll want a way to (eventually) remove the old, make the new one the default, add future ones, etc.
Describe the feature you'd like to see implemented
One approach would be to make Blueprinter::Base an alias to the "default" API version. So we'd move the existing code to Blueprinter::V1::Base and point Blueprinter::Base there. Blueprints could inherit from either name.
When we add V2, it would live at Blueprinter::V2::Base. When we drop V1, we'd point Blueprinter::Base at Blueprinter::V2::Base.
Other schemes are also possible - please suggest!
Describe alternatives you've considered
No response
Additional context
No response
Another possibility (voiced by @sandstrom in another thread I can't find rn) is to release V2 alongside V1 in a final 1.x series. Around the same time, we'd release V2 stand-alone in 2.0 as Blueprinter::Base, dropping V1 completely. Large apps that need to update gradually would stay on 1.x until they're finished, while smaller ones could jump right into 2.x.
Realistically there would be a period where we'd need to release V2 bugfixes to both the 1.x and 2.x series. So we'd probably need to keep around a semi-permanent branch for the 1.x series to backport V2 bugfixes into. I'm starting to think it's the "right" way to do it on paper, although it's potentially more overhead for us (depending on how many V2 bugs pop up).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Pondering how to soft-release V2. Obviously we could do alpha, beta, rc-* releases. But before that should we make some git tags off of release-2.0? That would let us (and others) try it against some real-world code and make sure we haven't overlooked something important.
Great that V2 is coming to fruition! 🎉
In my humble opinion, I'd just go for 'beta + 2.0 release', or 'RC + 2.0 release'.
Realistically there won't be a ton of people testing carefully through a long alpha, beta, RC process. For the same reason I'd also skip git tags not connected to releases -- just testing of master or pinning to a SHA in a gemfile should have roughly the same effect.