Proposal for versioning the ilab config file #117
Conversation
alimaredia
force-pushed
the
ilab-config-version
branch
from
cb68ac3
to
e5872f9
Compare
|
Versioning implies there is a schema for each version to support some compatibility across versions. Otherwise the version value is just an opaque identity that the cli either understands or does not. |
alimaredia
force-pushed
the
ilab-config-version
branch
4 times, most recently
from
1c87bc1
to
287d2d4
Compare
docs/schema/ilab-config-version.md
Outdated
|
|
||
| The `ilab` configuration file has a new `version` field at the top level of the config. | ||
|
|
||
| The value of `version` should start at `1.0`. |
There was a problem hiding this comment.
| The value of `version` should start at `1.0`. | |
| The value of `version` should start at `1`. |
I would just use a simple integer unless you plan to handle semantic versioning. Like where the cli handles all 1.x variants but not 2.x.
There was a problem hiding this comment.
Thanks for pushing the proposal @alimaredia.
Open question about versioning configuration. Should configuration be tied to a major release rather than versioning it? In other words, the configuration needs to be backwards compatible within a major release version but breaking changes can apply on the next major version.
In that case, we can change configuration that breaks backwards compatibility up until InstructLab 1.0.0 release.
Related to instructlab/instructlab/issues/1725 Signed-off-by: Ali Maredia <amaredia@redhat.com>
alimaredia
force-pushed
the
ilab-config-version
branch
from
287d2d4
to
5a1f912
Compare
|
@alimaredia what is going on with this? |
Related to instructlab/instructlab/issues/1725