I have a bunch of questions about unobvious behavior with collections, api and theirs versioning. Maybe i dont understand workflow with this sections of postman
So i creating API v0.1.0 with default schema (about user) and generate collection as documentation. After that add version tag 0.1.0 to collection. Then i create new version for API - v0.2.0 and made a change to ‘summary’ field of API schema. Finally i make same change to collection descrpition and tagging it with version tag 0.2.0. To this point everything seems legit and validation of documentation is good and green. But when i change my API version back to 0.1.0 i have bunch of problems:
first i have to rebind documentation collection, or i see v0.2.0 there for API version 0.1.0, it’s easy when you have one or two versions, but when it to hundred and you need to rebind all of them on new version release it’s like ‘bruh…’. Here is screenshoot of this, because i need to rebind collection for second part
second i can’t validate old versions, because it’s looks like it validating against ‘current’ collection version which always pointing to last ‘commit’ in collection, not choosed API version
Hey @Badou90,
Thanks for sharing, especially the public workspace link because then it makes the problem easier to understand. The mismatch happens when you use the same collection for 2 versions. A reason why I’ve probably not faced this issue before is, with every new version that I create, the collections/mock servers based on that API version are all new ones. I don’t use the old collection or modify it since that old collection was the source of truth for an older version. It could be that I’m supporting two versions at one time, hence.
In my head, adding a version tag to a collection would mean that it is compatible with or based on 0.1 or 0.2. In case it was initially 0.1, now 0.2, then it would now not validate with 0.1 so it shows issues. I’m sorry I’m not able to comprehend why you might want to modify a collection while upgrading instead of creating a new one. It would be a good idea to modify if I could tag each change. But one collection maps to one version tag at the moment, based on my understanding.
Please feel free to further expand on your case, I’d love to understand better. Also, welcome to the community
@Badou90 I’m reading your post again, and I just realized I don’t use the add version tag to add different tags for each change in the documentation. So I tried reproducing what you tried, and it does seem confusing when you go to a previous version. I see your point
@Badou90 there is a updated API versioning and tagging solution that was released in September. The recommended flow is to use create API versions for your major versions (e.g. v0 → v1), and create new “releases” for incremental changes to an existing version (e.g. 0.1.0 → 0.2.0 → 0.2.1, etc.). This alleviates the need to rebind all your collections when releasing a minor or patch update of a version. For more info, you can refer to this link in our Learning Center: Working with API Releases. Let us know about your experience and if this addresses the issues that you had raised.
