diff --git a/.ci/jobs/defaults.yml b/.ci/jobs/defaults.yml index d7d0bf3..dafc8d5 100755 --- a/.ci/jobs/defaults.yml +++ b/.ci/jobs/defaults.yml @@ -15,7 +15,7 @@ parameters: - string: name: branch_specifier - default: refs/heads/master + default: refs/heads/main description: the Git branch specifier to build (<branchName>, <tagName>, <commitId>, etc.) properties: diff --git a/.ci/jobs/elastic+eland+master.yml b/.ci/jobs/elastic+eland+master.yml index 3d28635..009e80d 100755 --- a/.ci/jobs/elastic+eland+master.yml +++ b/.ci/jobs/elastic+eland+master.yml @@ -1,13 +1,13 @@ --- - job: - name: elastic+eland+master - display-name: 'elastic / eland # master' + name: elastic+eland+main + display-name: 'elastic / eland # main' description: Eland is a data science client with a Pandas-like interface junit_results: "*-junit.xml" parameters: - string: name: branch_specifier - default: refs/heads/master + default: refs/heads/main description: The Git branch specifier to build triggers: - github diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5d658bb..fba4f70 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -94,7 +94,7 @@ Once your changes and tests are ready to submit for review: 3. Rebase your changes Update your local repository with the most recent code from the main - eland repository, and rebase your branch on top of the latest master + eland repository, and rebase your branch on top of the latest main branch. We prefer your initial changes to be squashed into a single commit. Later, if we ask you to make changes, add them as separate commits. This makes them easier to review. As a final step before @@ -119,8 +119,8 @@ Please adhere to the general guideline that you should never force push to a publicly shared branch. Once you have opened your pull request, you should consider your branch publicly shared. Instead of force pushing you can just add incremental commits; this is generally easier on your -reviewers. If you need to pick up changes from master, you can merge -master into your branch. A reviewer might ask you to rebase a +reviewers. If you need to pick up changes from main, you can merge +main into your branch. A reviewer might ask you to rebase a long-running pull request in which case force pushing is okay for that request. Note that squashing at the end of the review process should also not be done, that can be done when the pull request is [integrated diff --git a/README.md b/README.md index e93b4ad..0bde260 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@
- Eland
@@ -12,9 +12,9 @@ Downloads Package Status - Build Status - Build Status + License Documentation Status @@ -55,7 +55,7 @@ $ conda install -c conda-forge eland ### Connecting to Elasticsearch Eland uses the [Elasticsearch low level client](https://elasticsearch-py.readthedocs.io) to connect to Elasticsearch. -This client supports a range of [connection options and authentication options](https://elasticsearch-py.readthedocs.io/en/master/api.html#elasticsearch). +This client supports a range of [connection options and authentication options](https://elasticsearch-py.readthedocs.io/en/stable/api.html#elasticsearch). You can pass either an instance of `elasticsearch.Elasticsearch` to Eland APIs or a string containing the host to connect to: diff --git a/docs/sphinx/development/contributing.rst b/docs/sphinx/development/contributing.rst index 997aa54..540f62c 100644 --- a/docs/sphinx/development/contributing.rst +++ b/docs/sphinx/development/contributing.rst @@ -101,7 +101,7 @@ Once your changes and tests are ready to submit for review: 3. Rebase your changes Update your local repository with the most recent code from the main - eland repository, and rebase your branch on top of the latest master + eland repository, and rebase your branch on top of the latest main branch. We prefer your initial changes to be squashed into a single commit. Later, if we ask you to make changes, add them as separate commits. This makes them easier to review. As a final step before @@ -126,8 +126,8 @@ Please adhere to the general guideline that you should never force push to a publicly shared branch. Once you have opened your pull request, you should consider your branch publicly shared. Instead of force pushing you can just add incremental commits; this is generally easier on your -reviewers. If you need to pick up changes from master, you can merge -master into your branch. A reviewer might ask you to rebase a +reviewers. If you need to pick up changes from main, you can merge +main into your branch. A reviewer might ask you to rebase a long-running pull request in which case force pushing is okay for that request. Note that squashing at the end of the review process should also not be done, that can be done when the pull request is `integrated diff --git a/eland/ml/ml_model.py b/eland/ml/ml_model.py index efaeea6..04c6d7c 100644 --- a/eland/ml/ml_model.py +++ b/eland/ml/ml_model.py @@ -56,7 +56,7 @@ if TYPE_CHECKING: class MLModel: """ A machine learning model managed by Elasticsearch. - (See https://www.elastic.co/guide/en/elasticsearch/reference/master/put-inference.html) + (See https://www.elastic.co/guide/en/elasticsearch/reference/current/put-inference.html) These models can be created by Elastic ML, or transformed from supported Python formats such as scikit-learn or xgboost and imported into Elasticsearch.