Re: Versioning strategy for the specs, and RESTification

I agree that we should boldly move forward.  Moving towards being more  RESTful is important for adoption.   Versioning will help. On the data provider side I can imagine supporting both versions to enable OpenRefine to work (until it gets updated) and clients built on the latest version. 

Best regards,
Gregory

> On Jun 3, 2022, at 8:07 AM, Thad Guidry <thadguidry@gmail.com> wrote:
> 
> 
> I think we can be bold with any future changes since we will be versioning.  I don’t envision large programming efforts by users or institutions to adapt to new versions after .2
> 
> 
>> On Fri, Jun 3, 2022 at 6:45 AM Antonin Delpeuch <antonin@delpeuch.eu> wrote:
>> Hello all,
>> 
>> We have made quite some changes since version 0.1 of the protocol, but 
>> have not published them yet as a 0.2 version (for instance) that people 
>> can refer to. I would be in favor of doing that soon. Are there any 
>> changes you think should be made before that?
>> 
>> Additionally, and once that is done, I wonder what people would think of 
>> making bold changes to the API, as listed here:
>> 
>> https://github.com/reconciliation-api/specs/issues/84
>> 
>> This would likely result in a fairly incompatible spec. I feel like now 
>> is probably the time to do this: we have versioning in place, we can see 
>> that there is interest from multiple parties in having this fixed, and 
>> we have not transitioned to a Working Group yet (so we still have time 
>> for large changes).
>> 
>> I would be happy to hear how people think about this, because I think it 
>> would be quite some work, that I would be happy to do but I prefer to 
>> anticipate any blockers before starting to do it.
>> 
>> Best,
>> 
>> Antonin
>> 
>> 
> -- 
> Thad
> https://www.linkedin.com/in/thadguidry/
> https://calendly.com/thadguidry/