Plan for adding and deprecating new API versions

[jhollinger]

Is there an existing issue for this?

• 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

[jhollinger]

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).