-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC for steps to move to Refract 1.0 #13
base: master
Are you sure you want to change the base?
Conversation
As Refract is moving into production environments, we need to keep the following in mind: | ||
|
||
1. We want to have as a concise of a spec as necessary for newcomers | ||
1. We want to introduce breaking changes thoughtfully, which is what SemVer encourages. We currently can't do SemVer correctly without moving to 1.0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1.0.0 if we're using server 😉.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes, I was lazy :) I'll change.
|
||
This decoupling I think is important, because it gives freedom to implementors to implement the best way they see fit in their language/platform, and it allows for other serialization formats to spring up that may be helpful to others. | ||
|
||
**Proposal**: Explain the difference in the conceptual model and the serialization formats, and potentially move these serialization descriptions to their own file in the spec repo, separating them from the main spec. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also have a separate repo for each of these, if necessary.
I think we need to address the things mentioned in the RFC as part of 1.0.0. But I don't think we need to be hasty about it. I would like to have a bit more time and try refract in production first internally at Apiary so that we can change any breaking stuff first before moving to 1.0.0 For now, let's leave this PR as it is once everyone reviews it and keep adding to this if we come up with more stuff for 1.0.0 |
|
||
In order to get to 1.0.0, we need to think about whether we want to leave these kinds of things in the spec and change to them, or if we want to align the spec with what we've practically done. | ||
|
||
**Proposal**: Consider removing ability for namespaces to be lexically scoped on each element and make namespaces rather document-defined as we've done in our implementations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is currently being proposed in #22 as a way to move toward using hyperlinking instead of namespacing like this.
This does not mean we remove the current namespaces. It does mean that the namespace functionality in the current spec will be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also saw #31.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think #30 resolves this. Will update.
There are three things in this spec to accomplish. Namespacing is being discussed in another RFC and the other two are simply reorganizing some files. I propose we do these three things, yet still wait on moving completely to 1.0.0. If that works, I'll rework this RFC a bit to align with that idea and we can work on these few changes. |
|
||
In addition to moving to 1.0.0, we need to actually start versioning namespace documents. The reason for this is that we do not want a breaking change in a namespace to require a major version bump for the entire spec. | ||
|
||
**Proposal**: Start versioning current and future namespaces and move each namespace to their own repo. We can do this immediately. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have moved the discussion to here:
#34
@smizell This needs to be updated. |
a400b99
to
e8a3629
Compare
The serialisation has been done. And there is an issue tracking the inheritance on the Refract Spec. So, should we close this PR? |
This document outlines some things we should consider as we move Refract to production environments.