You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 18, 2020. It is now read-only.
sebinside opened this issue
Aug 12, 2019
· 2 comments
Assignees
Labels
apiRequires api changesbuildRequires changes to the build systemenhancementNew feature or requestguiRequires changes to the chatoverflow-gui (separate repo)ioRelies on a connector / input / output / parameterminorQuick to implement
As mentioned in #96 we should update the version numbers of all artifacts to match the API version and follow the rules of semantic versioning (major.minor.patch).
This includes:
API-Version (3.0)
Framework / API Impl Version (0.3 -> 3.0)
REST-API-Version (0.3 -> 3.0)
GUI-Version (0.3 -> 3.0)
npm-package version (0.3.8 -> 3.0)
Build environment (0.3 -> 3.0)
As we distribute everything built together right now and in the (near) feature, this might solve understanding problems. To be more flexible, allowing the artefacts to change their minor and patch number while ensuring compatibility with the major number, might be still a good idea.
E.g API-Version 3.1 with GUI-Version 3.2 and npm-package 3.2.4 should still work together, as far as semantic versioning goes. development versions could be also tagged with snapshot, but this will be more interesting when we start using maven to publish.
The text was updated successfully, but these errors were encountered:
sebinside
added
enhancement
New feature or request
minor
Quick to implement
io
Relies on a connector / input / output / parameter
gui
Requires changes to the chatoverflow-gui (separate repo)
api
Requires api changes
build
Requires changes to the build system
labels
Aug 12, 2019
Do we want to be the patch version of the api to just be a silent version for the jar and releases or do we want to make the framework aware of it by including it in the APIVersion class?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
apiRequires api changesbuildRequires changes to the build systemenhancementNew feature or requestguiRequires changes to the chatoverflow-gui (separate repo)ioRelies on a connector / input / output / parameterminorQuick to implement
Description
As mentioned in #96 we should update the version numbers of all artifacts to match the API version and follow the rules of semantic versioning (major.minor.patch).
This includes:
As we distribute everything built together right now and in the (near) feature, this might solve understanding problems. To be more flexible, allowing the artefacts to change their minor and patch number while ensuring compatibility with the major number, might be still a good idea.
E.g API-Version 3.1 with GUI-Version 3.2 and npm-package 3.2.4 should still work together, as far as semantic versioning goes.
development
versions could be also tagged withsnapshot
, but this will be more interesting when we start using maven to publish.The text was updated successfully, but these errors were encountered: