cloudevents
PROPOSAL: minor versions
This is an initial drafty proposal for how we might handle minor versions. It's intended for discussion as a pull request, although we could potentially end up with it in the working-drafts folder if we think the idea has merit but we're not quite ready to turn it into spec language yet.
Signed-off-by: Jon Skeet [email protected]
Thanks for the comments, Doug. I don't yet have a read on whether you think this is broadly going in the right direction or whether:
- It should be much looser, with far fewer restrictions anywhere, with increased risk of invalid events being propagated
- We should just abandon the idea of minor versions and stay with the status quo
I'm leaning towards just keeping things as they are today. Meaning, we can do minor versions (with new optional attributes) but the version string on the wire doesn't change. I say this because then it puts extensions and optional attributes on par with each other. One interesting thing to me is that the spec specifically says this about optional core attributes:
A consumer that does not support that feature will then silently ignore that part of the message.
To me, a consuming SDK that chooses to only know about required attributes should still expose the unsupported attributes to the user in some way - if nothing else as an extension attribute. This means that SDK supported attributes might have first class support (e.g. via ce10.source), but whether the SDK exposes the optional or extension attributes via ce10.xxx is an impl choice. And, I would argue that both optional and extensions could be supported via ce10.xxx.
Additionally, the concern about attribute conflicts (between new optional ones and extensions) would then apply equally between them. That symmetry is appealing to me.
But, I think it would help if you could add a short summary to your write-up that listed the short list of changes (or restrictions) an SDK, or code in general, would need to make to support your idea. That might help clarify exactly what the impact of your proposal would be on both SDKs and users.
I'm leaning towards just keeping things as they are today. Meaning, we can do minor versions (with new optional attributes) but the version string on the wire doesn't change.
That means an event which is valid today might not be valid tomorrow. (If it uses a string value for an unspecified extension attribute that becomes an optional integer attribute, for example.) That makes me really nervous - I don't see why we wouldn't highlight that change with a new version.
I don't have time to add anything more in this PR today (I'm going on vacation for a week starting tomorrow, which means lots of loose-end-tying with the day job) but I'll be at the meeting later and we can discuss it then. I think it would be good to try to agree on some principles, and then work out what that means for SDKs. (To me, the principle of "if it's valid today, it's valid tomorrow" is a really important one.)
That means an event which is valid today might not be valid tomorrow
Yup and I think I'm less nervous about it than you because to me that's the nature of extensions - no matter what you do you're at risk. Your example is an interesting one because (w/o proof) I kind of wonder how realistic it is since if we decide that we need "foo" added as an optional attribute you'd think that the odds of it being a different type (or at least a different set of valid chars) than the extension would be pretty low - unless folks did a really bad job at naming it. But, again, no proof :-)
Yup and I think I'm less nervous about it than you because to me that's the nature of extensions - no matter what you do you're at risk.
I don't think that's the case with the proposals in this PR. There's a risk that a valid v1.0 event wouldn't be valid as a v1.1 event, but that bothers me less - because the existing events could still flow through systems which are upgraded to be aware of 1.1.
Your example is an interesting one because (w/o proof) I kind of wonder how realistic it is since if we decide that we need "foo" added as an optional attribute you'd think that the odds of it being a different type (or at least a different set of valid chars) than the extension would be pretty low.
I agree that it's reasonably unlikely - but I'd still like to eliminate that risk if possible.
Per discussion; regarding X- https://datatracker.ietf.org/doc/html/rfc6648
The more I think about my C compiler comparison the more I like it :-) because for the most part there aren't versions involved - it's just "cc myapp.c" and so I think looking at how people deal with that might be a fair comparison.
If my compiler defines an extension that eventually conflicts with the standard C lang definition, then when I upgrade my compiler (assuming they change things to be compliant) then my code will most likely not compile cleanly - no promise that an old program will work with the latest (or different C) compiler if I use extensions. That's just the risk of defining and using extensions.
TBH this is partially why I sometimes wish we didn't have a version string at all - it gives a false sense of security. Kind of like how we tell people "if you stick with the Kubernetes resources your app is 100% portable" or the "v1" part of the of the K8s version strings guarantee compatibility :-)
On the Sept 1 call we agreed to close this for now but really put it "on hold" until we have a concrete need to address. Jon will keep the branch around for people to read if they want.