Home
last modified time | relevance | path

Searched +full:update +full:- +full:docs +full:- +full:branch (Results 1 – 25 of 474) sorted by relevance

12345678910>>...19

/external/aws-crt-java/.github/workflows/
Ddocs.yml1 # Update the API documentation whenever the `main` branch changes.
2 # This documentation lives in its own `docs` branch.
3 name: docs
8 - 'main'
11 update-docs-branch:
12 runs-on: ubuntu-20.04 # latest
16 - name: Checkout
21 - name: Update docs branch
23 ./make-docs.sh
25 - name: Commit
[all …]
/external/OpenCSD/
DREADME.md1 OpenCSD - An open source CoreSight(tm) Trace Decode library {#mainpage}
15 ------------------
25 Releases will appear on the master branch in the git repository with an appropriate version tag.
28 ----------------------------------
34 - ETE (v1.3) instruction trace - packet processing and packet decode.
35 - ETMv4 (v4.6 [A/R profile] v4.4 [M profile]) instruction trace - packet processing and packet deco…
36 - PTM (v1.1) instruction trace - packet processing and packet decode.
37 - ETMv3 (v3.5) instruction trace - packet processing and packet decode.
38 - ETMv3 (v3.5) data trace - packet processing.
39 - STM (v1.1) software trace - packet processing and packet decode.
[all …]
/external/fmtlib/support/
Dbuild-docs.py15 # Build the docs.
23 branch = os.environ['GITHUB_REF'] variable
25 if is_ci and branch != 'refs/heads/master':
26 print('Branch: ' + branch)
27 exit(0) # Ignore non-master branches
29 # Don't update the repo if building in CI from an account that doesn't have
31 print('Skipping update of ' + repo)
39 # Copy docs to the repo.
44 check_call(['git', 'config', '--global', 'user.name', 'fmtbot'])
45 check_call(['git', 'config', '--global', 'user.email', 'viz@fmt.dev'])
[all …]
Dmanage.py6 manage.py release [<branch>]
52 def update(self, *args): member in Git
59 def clean_checkout(repo, branch): argument
60 repo.clean('-f', '-d')
61 repo.reset('--hard')
62 repo.checkout(branch)
115 env.fmt_repo.update(fmt_repo_url)
118 doc_repo.update('git@github.com:fmtlib/fmtlib.github.io')
129 for entry in ['_static', '_templates', 'basic-bootstrap', 'bootstrap',
171 'fmt::format_to(OutputIt, const S&, Args&&...) -> ' +
[all …]
/external/perfetto/docs/visualization/
Dperfetto-ui-release-process.md6 - `stable`, the version served by default on ui.perfetto.dev.
8 - `canary`, a less stable but fresher release. Updated every 1-2 weeks.
9 - `autopush`, the current HEAD version of the UI. Unstable.
13 - Week 1: Update `canary` to `HEAD`.
14 - Week 2: Update `canary` to `HEAD`.
16 Only critical bug fixes can be cherry-picked onto `canary`.
17 - Week 3: Canary stabilization week 2/2.
18 - Week 4: Update `stable` to current `canary`, update `canary` to `HEAD`.
23 - Canary soaks for two weeks before being promoted to stable.
24 - Newer features can be tried out in Canary within a week, or two at most (if
[all …]
/external/kotlinx.coroutines/
DCONTRIBUTING.md11 …`#coroutines` channel in [KotlinLang Slack](https://surveys.jetbrains.com/s3/kotlin-slack-sign-up).
19 * All development (both new features and bug fixes) is performed in the `develop` branch.
20 * The `master` branch contains the sources of the most recently released version.
21 * Base your PRs against the `develop` branch.
22 * The `develop` branch is pushed to the `master` branch during release.
23 * Documentation in markdown files can be updated directly in the `master` branch,
26 …* After fixing/changing code examples in the [`docs`](docs) folder or updating any references in t…
27 run the [Knit tool](#running-the-knit-tool) and commit the resulting changes as well.
29 …If you plan extensive rewrites/additions to the docs, then please [contact the maintainers](#conta…
32 …* Follow the [Kotlin Coding Conventions](https://kotlinlang.org/docs/reference/coding-conventions.…
[all …]
/external/kotlinx.serialization/
DCONTRIBUTING.md23 * Explain why you need the feature &mdash; what's your use-case, what's your domain.
34 * All development (both new features and bug fixes) is performed in the `dev` branch.
35 * The `master` branch always contains sources of the most recently released version.
36 * Base PRs against the `dev` branch.
37 * The `dev` branch is pushed to the `master` branch during release.
38 * Documentation in markdown files can be updated directly in the `master` branch,
41 …* After fixing/changing code examples in the [`docs`](docs) folder or updating any references in t…
42 run the [Knit tool](#running-the-knit-tool) and commit the resulting changes as well.
44 …If you plan extensive rewrites/additions to the docs, then please [contact the maintainers](#conta…
47 …* Follow the [Kotlin Coding Conventions](https://kotlinlang.org/docs/reference/coding-conventions.…
[all …]
DRELEASING.md5 1. Checkout `dev` branch and update:<br>
8 3. Make sure the `master` branch is fully merged into `dev`:<br>
11 4. Search & replace `<old-version>` with `<version>` across the project files. Should replace in:
14 * [`integration-test/gradle.properties`](integration-test/gradle.properties)
16 Update Kotlin version, if necessary.
23 …[git changelog](https://github.com/tj/git-extras/blob/master/Commands.md#git-changelog) from git-e…
25 …ry, commit your changes to a new branch called `<version>-release` and send it for review, then me…
32 `git push origin dev && git push origin --tags`
35 …* Wait until "Runtime library (Build – Aggregated)" configuration for committed `dev` branch passe…
36 * Run "Runtime library (Deploy - Train)" configuration:
[all …]
/external/accompanist/docs/
Dupdating.md6 All new features should be uploaded as PRs against the `main` branch.
8 Once merged into `main`, they will be automatically merged into the `snapshot` branch.
12 …ich depend on a `SNAPSHOT` versions of Jetpack Compose. These are built from the `snapshot` branch.
16 …e, updating to a new Compose snapshot is done by submitting a new PR against the `snapshot` branch:
20 # Create branch for PR
21 git checkout -b update_snapshot
30 1. Update the `composesnapshot` property to be the snapshot number
40 Finally create a PR (with the base branch as `snapshot`) and send for review.
48 First we merge the `snapshot` branch into `main`:
54 # Create branch for PR
[all …]
/external/google-cloud-java/java-retail/google-cloud-retail/src/main/java/com/google/cloud/retail/v2/
DProductServiceClient.java8 * https://www.apache.org/licenses/LICENSE-2.0
42 // AUTO-GENERATED DOCUMENTATION AND CLASS.
53 * // - It may require correct/in-range values for request initialization.
54 * // - It may require specifying regional endpoints when creating the service client as shown in
55 * // https://cloud.google.com/java/docs/setup#configure_endpoints_for_the_client_library
57 * BranchName parent = BranchName.of("[PROJECT]", "[LOCATION]", "[CATALOG]", "[BRANCH]");
59 * String productId = "productId-1051830678";
65 * as threads. In the example above, try-with-resources is used, which automatically calls close().
95 * // - It may require correct/in-range values for request initialization.
96 * // - It may require specifying regional endpoints when creating the service client as shown in
[all …]
DCatalogServiceClient.java8 * https://www.apache.org/licenses/LICENSE-2.0
37 // AUTO-GENERATED DOCUMENTATION AND CLASS.
47 * // - It may require correct/in-range values for request initialization.
48 * // - It may require specifying regional endpoints when creating the service client as shown in
49 * // https://cloud.google.com/java/docs/setup#configure_endpoints_for_the_client_library
58 * as threads. In the example above, try-with-resources is used, which automatically calls close().
88 * // - It may require correct/in-range values for request initialization.
89 * // - It may require specifying regional endpoints when creating the service client as shown in
90 * // https://cloud.google.com/java/docs/setup#configure_endpoints_for_the_client_library
103 * // - It may require correct/in-range values for request initialization.
[all …]
/external/google-cloud-java/java-retail/google-cloud-retail/src/main/java/com/google/cloud/retail/v2beta/
DProductServiceClient.java8 * https://www.apache.org/licenses/LICENSE-2.0
42 // AUTO-GENERATED DOCUMENTATION AND CLASS.
53 * // - It may require correct/in-range values for request initialization.
54 * // - It may require specifying regional endpoints when creating the service client as shown in
55 * // https://cloud.google.com/java/docs/setup#configure_endpoints_for_the_client_library
57 * BranchName parent = BranchName.of("[PROJECT]", "[LOCATION]", "[CATALOG]", "[BRANCH]");
59 * String productId = "productId-1051830678";
65 * as threads. In the example above, try-with-resources is used, which automatically calls close().
95 * // - It may require correct/in-range values for request initialization.
96 * // - It may require specifying regional endpoints when creating the service client as shown in
[all …]
DCatalogServiceClient.java8 * https://www.apache.org/licenses/LICENSE-2.0
38 // AUTO-GENERATED DOCUMENTATION AND CLASS.
48 * // - It may require correct/in-range values for request initialization.
49 * // - It may require specifying regional endpoints when creating the service client as shown in
50 * // https://cloud.google.com/java/docs/setup#configure_endpoints_for_the_client_library
59 * as threads. In the example above, try-with-resources is used, which automatically calls close().
89 * // - It may require correct/in-range values for request initialization.
90 * // - It may require specifying regional endpoints when creating the service client as shown in
91 * // https://cloud.google.com/java/docs/setup#configure_endpoints_for_the_client_library
104 * // - It may require correct/in-range values for request initialization.
[all …]
/external/google-cloud-java/java-retail/google-cloud-retail/src/main/java/com/google/cloud/retail/v2alpha/
DProductServiceClient.java8 * https://www.apache.org/licenses/LICENSE-2.0
42 // AUTO-GENERATED DOCUMENTATION AND CLASS.
53 * // - It may require correct/in-range values for request initialization.
54 * // - It may require specifying regional endpoints when creating the service client as shown in
55 * // https://cloud.google.com/java/docs/setup#configure_endpoints_for_the_client_library
57 * BranchName parent = BranchName.of("[PROJECT]", "[LOCATION]", "[CATALOG]", "[BRANCH]");
59 * String productId = "productId-1051830678";
65 * as threads. In the example above, try-with-resources is used, which automatically calls close().
95 * // - It may require correct/in-range values for request initialization.
96 * // - It may require specifying regional endpoints when creating the service client as shown in
[all …]
DCatalogServiceClient.java8 * https://www.apache.org/licenses/LICENSE-2.0
38 // AUTO-GENERATED DOCUMENTATION AND CLASS.
48 * // - It may require correct/in-range values for request initialization.
49 * // - It may require specifying regional endpoints when creating the service client as shown in
50 * // https://cloud.google.com/java/docs/setup#configure_endpoints_for_the_client_library
59 * as threads. In the example above, try-with-resources is used, which automatically calls close().
89 * // - It may require correct/in-range values for request initialization.
90 * // - It may require specifying regional endpoints when creating the service client as shown in
91 * // https://cloud.google.com/java/docs/setup#configure_endpoints_for_the_client_library
104 * // - It may require correct/in-range values for request initialization.
[all …]
/external/mesa3d/docs/
Dreleasing.rst5 --------
8 being the stable branch name.
11 version (Z), while the latter have a non-zero one.
17 Mesa 10.1.0 - 10.1 branch, feature
18 Mesa 10.1.4 - 10.1 branch, bugfix
19 Mesa 12.0.0 - 12.0 branch, feature
20 Mesa 12.0.2 - 12.0 branch, bugfix
25 ----------------
30 See our :doc:`calendar <release-calendar>` for information about how
35 ----------------
[all …]
Dsubmittingpatches.rst7 ----------------
9 - Patches should not mix code changes with code formatting changes
11 - Code patches should follow Mesa :doc:`coding
13 - Whenever possible, patches should only affect individual Mesa/Gallium
15 - Patches should never introduce build breaks and should be bisectable
17 - Patches should be properly :ref:`formatted <formatting>`.
18 - Patches should be sufficiently :ref:`tested <testing>` before
20 - Patches should be :ref:`submitted <submit>` via a merge request for
26 ----------------
28 - Lines should be limited to 75 characters or less so that Git logs
[all …]
/external/mesa3d/bin/
Dpost_version.py2 # Copyright © 2019-2020 Intel Corporation
22 """Update the main page, release notes, and calendar."""
30 def update_calendar(version: str) -> None:
31 p = pathlib.Path('docs') / 'release-calendar.csv'
36 branch = None
40 branch = line[0]
42 if branch is not None:
43 calendar[i + 1][0] = branch
53 def main() -> None:
60 subprocess.run(['git', 'commit', '-m',
[all …]
/external/skia/site/docs/dev/contrib/
Dsubmit.md1 ---
4 ---
8 <!--?prettify lang=sh?-->
10 git config --global user.name "Your Name"
11 git config --global user.email you@example.com
15 First create a branch for your changes:
17 <!--?prettify lang=sh?-->
19 git config branch.autosetuprebase always
20 git checkout -b my_feature origin/main
24 <!--?prettify lang=sh?-->
[all …]
/external/cronet/third_party/libc++/src/docs/
DReleaseProcedure.rst8 `schedule <https://llvm.org/docs/HowToReleaseLLVM.html#annual-release-schedule>`__.
19 * Make sure ``libcxx/docs/ReleaseNotes/<VERSION>.rst`` is up to date. Typically
47 1. Update ``_LIBCPP_VERSION`` in ``libcxx/include/__config``
48 2. Update the version number in ``libcxx/docs/conf.py``
49 3. Update ``_LIBCPPABI_VERSION`` in ``libcxxabi/include/cxxabi.h``
50 4. Update ``_LIBUNWIND_VERSION`` in ``libunwind/include/__libunwind_config.h``
52 6. Point to the new release notes file from ``libcxx/docs/index.rst``
60 available on `<https://apt.llvm.org>`_. Once it is available the pre-commit CI
62 backported to the release branch the oldest compiler is not removed yet.
67 The items that need changing are marked with ``LLVM POST-BRANCH``.
[all …]
/external/mesa3d/src/gfxstream/codegen/vulkan/vulkan-docs-next/xml/
DREADME.adoc1 // Copyright 2014-2023 The Khronos Group Inc.
3 // SPDX-License-Identifier: CC-BY-4.0
29 * Clone the repository and create a branch to work in locally
34 of platform-dependent headers `vulkan_<platform>.h`; and runs a simple
44 * Commit your changes to your local git branch, push to your upstream git
45 server (your personal repository clone of KhronosGroup/Vulkan-Docs on
48 branch (currently `main`) or other appropriate target.
78 We strongly recommend using the Khronos-provided Docker image, which has all
79 needed build tools pre-installed.
83 MacOS by following the recipe in the Dockerfile for the Khronos-provided
[all …]
/external/rust/crates/coset/scripts/
Dbuild-gh-pages.sh8 # http://www.apache.org/licenses/LICENSE-2.0
16 set -o errexit
17 set -o nounset
18 set -o xtrace
19 set -o pipefail
21 # Update the gh-pages branch. Note that `cargo doc` is **not deterministic** so
23 readonly RUST_BRANCH=${1:-main}
24 readonly RUST_GH_BRANCH=gh-pages
26 if [ -z "${FORCE+x}" ]; then
27 …readonly PREV_COMMIT=$(git log --oneline -n 1 ${RUST_GH_BRANCH} | sed 's/.*branch at \([0-9a-f]*\)…
[all …]
/external/perfetto/docs/contributing/
Dsdk-releasing.md5 Before snapshotting a release, check that no [release-blockers](http://b/savedsearches/5776355) are
18 release (cherry-picks on the releases/vN.x branch).
24 Make sure that the current main branch builds on
25 [LUCI](https://luci-scheduler.appspot.com/jobs/perfetto) by triggering all the
34 running `perfetto --version` should show your new version number.
36 Upload the CHANGELOG change and submit it on the main branch.
38 Create a release branch for the new major version ("v16.x" here):
44 git checkout -b releases/v16.x -t origin/releases/v16.x
47 Continue with [building the release](#building-and-tagging-the-release).
51 Check out the existing release branch ("5.x" here) and merge in the desired
[all …]
/external/cronet/third_party/boringssl/src/
DINCORPORATING.md7 ["go/boringssl-on-new-platform"](https://goto.corp.google.com/boringssl-on-new-platform) (Google
11 ## Which branch to use
14 ["live at head"](https://abseil.io/about/philosophy#we-recommend-that-you-choose-to-live-at-head)
16 of update, and regularly update it to pick up new changes.
18 While the BoringSSL repository may contain project-specific branches, e.g.
19 `chromium-2214`, those are _not_ supported release branches and must not as
20 such. In rare cases, BoringSSL will temporarily maintain a short-lived branch on
24 branch has a corresponding BoringSSL `chromium-*` branch. Even while active, the
25 branch may not contain all changes relevant to a general BoringSSL consumer.
31 `master-with-bazel` branch. That branch is maintained by a bot from `master`
[all …]
/external/boringssl/src/
DINCORPORATING.md7 ["go/boringssl-on-new-platform"](https://goto.corp.google.com/boringssl-on-new-platform) (Google
11 ## Which branch to use
14 ["live at head"](https://abseil.io/about/philosophy#we-recommend-that-you-choose-to-live-at-head)
16 of update, and regularly update it to pick up new changes.
18 While the BoringSSL repository may contain project-specific branches, e.g.
19 `chromium-2214`, those are _not_ supported release branches and must not as
20 such. In rare cases, BoringSSL will temporarily maintain a short-lived branch on
24 branch has a corresponding BoringSSL `chromium-*` branch. Even while active, the
25 branch may not contain all changes relevant to a general BoringSSL consumer.
31 `master-with-bazel` branch. That branch is maintained by a bot from `master`
[all …]

12345678910>>...19