Tasks: Graduate the tasks API from beta #34245
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The tasks API has been around for a while now and we haven't changed it in backwards incompatible ways for a long time now. I think we're more than ready to graduate the tasks APIs from beta. This doesn't mean that we won't change *how* these APIs work, just that we won't change the REST API without a deprecation period.
nik9000
added
>docs
Collaborator
|
Pinging @elastic/es-distributed |
tlrx
approved these changes
Oct 2, 2018
Member
Author
|
Looks like we want #34249 first. |
nik9000
added a commit
to nik9000/elasticsearch
that referenced
this pull request
Oct 3, 2018
The `status` part of the tasks API reflects the internal status of a running task. In general, we do not make backwards breaking changes to the `status` but because it is internal we reserve the right to do so. I suspect we will very rarely excercise that right but it is important that we have it so we're not boxed into any particular implementation for a request. In some sense this is policy making by documentation change. In another it is clarification of the way we've always thought of this field. I also reflect the documentation change into the Javadoc in a few places. There I acknowledge Kibana's "special relationship" with Elasticsearch. Kibana parses `_reindex`'s `status` field and, because we're friends with those folks, we should talk to them before we make backwards breaking changes to it. We *want* to be friends with everyone but there is only so much time in the day and we don't *want* to make backwards breaking fields to `status` at all anyway. So we hope that breaking changes documentation should be enough for other folks. Relates to elastic#34245.
nik9000
added a commit
that referenced
this pull request
Oct 4, 2018
The `status` part of the tasks API reflects the internal status of a running task. In general, we do not make backwards breaking changes to the `status` but because it is internal we reserve the right to do so. I suspect we will very rarely excercise that right but it is important that we have it so we're not boxed into any particular implementation for a request. In some sense this is policy making by documentation change. In another it is clarification of the way we've always thought of this field. I also reflect the documentation change into the Javadoc in a few places. There I acknowledge Kibana's "special relationship" with Elasticsearch. Kibana parses `_reindex`'s `status` field and, because we're friends with those folks, we should talk to them before we make backwards breaking changes to it. We *want* to be friends with everyone but there is only so much time in the day and we don't *want* to make backwards breaking fields to `status` at all anyway. So we hope that breaking changes documentation should be enough for other folks. Relates to #34245.
nik9000
added a commit
that referenced
this pull request
Oct 4, 2018
The `status` part of the tasks API reflects the internal status of a running task. In general, we do not make backwards breaking changes to the `status` but because it is internal we reserve the right to do so. I suspect we will very rarely excercise that right but it is important that we have it so we're not boxed into any particular implementation for a request. In some sense this is policy making by documentation change. In another it is clarification of the way we've always thought of this field. I also reflect the documentation change into the Javadoc in a few places. There I acknowledge Kibana's "special relationship" with Elasticsearch. Kibana parses `_reindex`'s `status` field and, because we're friends with those folks, we should talk to them before we make backwards breaking changes to it. We *want* to be friends with everyone but there is only so much time in the day and we don't *want* to make backwards breaking fields to `status` at all anyway. So we hope that breaking changes documentation should be enough for other folks. Relates to #34245.
kcm
pushed a commit
that referenced
this pull request
Oct 30, 2018
The `status` part of the tasks API reflects the internal status of a running task. In general, we do not make backwards breaking changes to the `status` but because it is internal we reserve the right to do so. I suspect we will very rarely excercise that right but it is important that we have it so we're not boxed into any particular implementation for a request. In some sense this is policy making by documentation change. In another it is clarification of the way we've always thought of this field. I also reflect the documentation change into the Javadoc in a few places. There I acknowledge Kibana's "special relationship" with Elasticsearch. Kibana parses `_reindex`'s `status` field and, because we're friends with those folks, we should talk to them before we make backwards breaking changes to it. We *want* to be friends with everyone but there is only so much time in the day and we don't *want* to make backwards breaking fields to `status` at all anyway. So we hope that breaking changes documentation should be enough for other folks. Relates to #34245.
Contributor
|
Closing for now, pending someone picking up #34249 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The tasks API has been around for a while now and we haven't changed it
in backwards incompatible ways for a long time now. I think we're more
than ready to graduate the tasks APIs from beta.
This doesn't mean that we won't change how these APIs work, just that
we won't change the REST API without a deprecation period.