We probably need `stableSchemas` in npm package
Opened this issue · 9 comments
most of the context is in: #421 (comment)
now we have
module.exports = {
'schemas': {
'2.0.0': require('./schemas/2.0.0.json'),
'2.1.0': require('./schemas/2.1.0.json'),
'2.2.0': require('./schemas/2.2.0.json'),
'2.3.0': require('./schemas/2.3.0.json'),
'2.4.0': require('./schemas/2.4.0.json'),
'2.5.0': require('./schemas/2.5.0.json'),
'2.6.0': require('./schemas/2.6.0.json'),
'3.0.0': require('./schemas/2.6.0.json')
},
'schemasWithoutId': {
'2.0.0': require('./schemas/2.0.0-without-$id.json'),
'2.1.0': require('./schemas/2.1.0-without-$id.json'),
'2.2.0': require('./schemas/2.2.0-without-$id.json'),
'2.3.0': require('./schemas/2.3.0-without-$id.json'),
'2.4.0': require('./schemas/2.4.0-without-$id.json'),
'2.5.0': require('./schemas/2.5.0-without-$id.json'),
'2.6.0': require('./schemas/2.6.0-without-$id.json'),
'3.0.0': require('./schemas/2.6.0-without-$id.json'),
}
};
with new release strategy that comes with v6 of this repo, new releases of spec like for example 3.1.0
will look like below - even if not yet officially released and in pre release state
module.exports = {
'schemas': {
'2.0.0': require('./schemas/2.0.0.json'),
'2.1.0': require('./schemas/2.1.0.json'),
'2.2.0': require('./schemas/2.2.0.json'),
'2.3.0': require('./schemas/2.3.0.json'),
'2.4.0': require('./schemas/2.4.0.json'),
'2.5.0': require('./schemas/2.5.0.json'),
'2.6.0': require('./schemas/2.6.0.json'),
'3.0.0': require('./schemas/3.0.0.json'),
'3.1.0': require('./schemas/3.1.0.json')
},
'schemasWithoutId': {
'2.0.0': require('./schemas/2.0.0-without-$id.json'),
'2.1.0': require('./schemas/2.1.0-without-$id.json'),
'2.2.0': require('./schemas/2.2.0-without-$id.json'),
'2.3.0': require('./schemas/2.3.0-without-$id.json'),
'2.4.0': require('./schemas/2.4.0-without-$id.json'),
'2.5.0': require('./schemas/2.5.0-without-$id.json'),
'2.6.0': require('./schemas/2.6.0-without-$id.json'),
'3.0.0': require('./schemas/3.0.0-without-$id.json'),
'3.1.0': require('./schemas/3.1.0-without-$id.json'),
}
};
This means that developers will need to accept all they get with schemas
and accept possible breaking changes in unstable schemas, or take schemas
in a way that they "manually" decide that only schemas prior some specific release are used by them
so people do not have to decide on ☝🏼 how to figure out which schemas are stable or not, we can introduce new object stableSchemas
where taking above example, 3.1.0
would not be included until the official release of AsyncAPI 3.1
I am on it
This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience ❤️
I am on it
Any update on this @aayushRedHat ?
I am on it
Any update on this @aayushRedHat ?
@smoya Sorry i missed this one, pinged with another email
I am on it
Any update on this @aayushRedHat ?
@smoya Sorry i missed this one, pinged with another email
By any chance, did you start working on this? Still willing to?
I am on it
Any update on this @aayushRedHat ?
@smoya Sorry i missed this one, pinged with another email
By any chance, did you start working on this? Still willing to?
I didn't start on this, I am working on another issue, We can assign to someone else. Sorry
stableSchemas
The idea is to add a new key to the exported map named stableSchemas
where all stable schemas (no pre-released) are listed; at this very moment, a copy of the elements in schemas
key.
This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience ❤️