release: v3.30.0

* feat: remote taskfiles over http

* feat: allow insecure connections when --insecure flag is provided

* feat: better error handling for fetch errors

* fix: ensure cache directory always exists

* fix: setup logger before everything else

* feat: put remote taskfiles behind an experiment

* feat: --download and --offline flags for remote taskfiles

* feat: node.Read accepts a context

* feat: experiment docs

* chore: changelog

* chore: remove unused optional param from Node interface

* chore: tidy up and generalise NewNode function

* fix: use sha256 in remote checksum

* feat: --download by itself will not run a task

* feat: custom error if remote taskfiles experiment is not enabled

* refactor: BaseNode functional options and simplified FileNode

* fix: use hex encoding for checksum instead of b64

.github/workflows/lint.yml

@@ -14,7 +14,7 @@ jobs:
     steps:
       - uses: actions/setup-go@v3
         with:
-          go-version: 1.20.x
+          go-version: 1.21.x
 
       - uses: actions/checkout@v3
 

.github/workflows/release.yml

@@ -15,12 +15,12 @@ jobs:
       - name: Set up Go
         uses: actions/setup-go@v3
         with:
-          go-version: 1.20.x
+          go-version: 1.21.x
 
       - name: Run GoReleaser
         uses: goreleaser/goreleaser-action@v2
         with:
           version: latest
-          args: release --rm-dist
+          args: release --clean
         env:
           GITHUB_TOKEN: ${{secrets.GH_PAT}}

.goreleaser.yml

@@ -113,6 +113,7 @@ winget:
       - task-runner
       - taskfile
       - tool
+    skip_upload: true
     repository:
       owner: microsoft
       name: winget-pkgs

CHANGELOG.md

@@ -1,11 +1,18 @@
 # Changelog
 
+## v3.30.0 - 2023-09-13
+
+- Prep work for Remote Taskfiles (#1316 by @pd93).
+- Added the
+  [Remote Taskfiles experiment](https://taskfile.dev/experiments/remote-taskfiles)
+  as a draft (#1152, #1317 by @pd93).
+- Improve performance of content checksuming on `sources:` by replacing md5 with
+  [XXH3](https://xxhash.com/) which is much faster. This is a soft breaking
+  change because checksums will be invalidated when upgrading to this release
+  (#1325 by @ReillyBrogan).
+
 ## v3.29.1 - 2023-08-26
 
-- Fix automate release process.
-
-## v3.29.0 - 2023-08-26
-
 - Update to Go 1.21 (bump minimum version to 1.20) (#1302 by @pd93)
 - Fix a missing a line break on log when using `--watch` mode (#1285, #1297 by
   @FilipSolich).
@@ -13,8 +20,8 @@
 - Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in
   combination with `includes` (#1046, #1205, #1250, #1293, #1312, #1274 by
   @andarto, #1309 by @andreynering).
-- Fix bug on `--status` flag. Running this flag should not have side-effects:
-  it should not update the checksum on `.task`, only report its status (#1305,
+- Fix bug on `--status` flag. Running this flag should not have side-effects: it
+  should not update the checksum on `.task`, only report its status (#1305,
   #1307 by @visciang, #1313 by @andreynering).
 
 ## v3.28.0 - 2023-07-24
@@ -42,7 +49,8 @@
 - Bug fixes were made to the
   [npm installation method](https://taskfile.dev/installation/#npm). (#1190, by
   @sounisi5011).
-- Added the [gentle force experiment](https://taskfile.dev/experiments) as a
+- Added the
+  [gentle force experiment](https://taskfile.dev/experiments/gentle-force) as a
   draft (#1200, #1216 by @pd93).
 - Added an `--experiments` flag to allow you to see which experiments are
   enabled (#1242 by @pd93).

args/args.go

@@ -8,7 +8,7 @@ import (
 
 // ParseV3 parses command line argument: tasks and global variables
 func ParseV3(args ...string) ([]taskfile.Call, *taskfile.Vars) {
-	var calls []taskfile.Call
+	calls := []taskfile.Call{}
 	globals := &taskfile.Vars{}
 
 	for _, arg := range args {
@@ -21,16 +21,12 @@ func ParseV3(args ...string) ([]taskfile.Call, *taskfile.Vars) {
 		globals.Set(name, taskfile.Var{Static: value})
 	}
 
-	if len(calls) == 0 {
-		calls = append(calls, taskfile.Call{Task: "default", Direct: true})
-	}
-
 	return calls, globals
 }
 
 // ParseV2 parses command line argument: tasks and vars of each task
 func ParseV2(args ...string) ([]taskfile.Call, *taskfile.Vars) {
-	var calls []taskfile.Call
+	calls := []taskfile.Call{}
 	globals := &taskfile.Vars{}
 
 	for _, arg := range args {
@@ -51,10 +47,6 @@ func ParseV2(args ...string) ([]taskfile.Call, *taskfile.Vars) {
 		}
 	}
 
-	if len(calls) == 0 {
-		calls = append(calls, taskfile.Call{Task: "default", Direct: true})
-	}
-
 	return calls, globals
 }
 

args/args_test.go

@@ -73,22 +73,16 @@ func TestArgsV3(t *testing.T) {
 			},
 		},
 		{
-			Args: nil,
-			ExpectedCalls: []taskfile.Call{
-				{Task: "default", Direct: true},
-			},
+			Args:          nil,
+			ExpectedCalls: []taskfile.Call{},
 		},
 		{
-			Args: []string{},
-			ExpectedCalls: []taskfile.Call{
-				{Task: "default", Direct: true},
-			},
+			Args:          []string{},
+			ExpectedCalls: []taskfile.Call{},
 		},
 		{
-			Args: []string{"FOO=bar", "BAR=baz"},
-			ExpectedCalls: []taskfile.Call{
-				{Task: "default", Direct: true},
-			},
+			Args:          []string{"FOO=bar", "BAR=baz"},
+			ExpectedCalls: []taskfile.Call{},
 			ExpectedGlobals: &taskfile.Vars{
 				OrderedMap: orderedmap.FromMapWithOrder(
 					map[string]taskfile.Var{
@@ -191,22 +185,16 @@ func TestArgsV2(t *testing.T) {
 			},
 		},
 		{
-			Args: nil,
-			ExpectedCalls: []taskfile.Call{
-				{Task: "default", Direct: true},
-			},
+			Args:          nil,
+			ExpectedCalls: []taskfile.Call{},
 		},
 		{
-			Args: []string{},
-			ExpectedCalls: []taskfile.Call{
-				{Task: "default", Direct: true},
-			},
+			Args:          []string{},
+			ExpectedCalls: []taskfile.Call{},
 		},
 		{
-			Args: []string{"FOO=bar", "BAR=baz"},
-			ExpectedCalls: []taskfile.Call{
-				{Task: "default", Direct: true},
-			},
+			Args:          []string{"FOO=bar", "BAR=baz"},
+			ExpectedCalls: []taskfile.Call{},
 			ExpectedGlobals: &taskfile.Vars{
 				OrderedMap: orderedmap.FromMapWithOrder(
 					map[string]taskfile.Var{

cmd/release/main.go

@@ -19,7 +19,7 @@ const (
 
 const changelogTemplate = `---
 slug: /changelog/
-sidebar_position: 9
+sidebar_position: 14
 ---`
 
 var (

cmd/task/task.go

@@ -53,6 +53,7 @@ var flags struct {
 	listJson    bool
 	taskSort    string
 	status      bool
+	insecure    bool
 	force       bool
 	forceAll    bool
 	watch       bool
@@ -71,6 +72,8 @@ var flags struct {
 	interval    time.Duration
 	global      bool
 	experiments bool
+	download    bool
+	offline     bool
 }
 
 func main() {
@@ -112,6 +115,7 @@ func run() error {
 	pflag.BoolVarP(&flags.listJson, "json", "j", false, "Formats task list as JSON.")
 	pflag.StringVar(&flags.taskSort, "sort", "", "Changes the order of the tasks when listed. [default|alphanumeric|none].")
 	pflag.BoolVar(&flags.status, "status", false, "Exits with non-zero exit code if any of the given tasks is not up-to-date.")
+	pflag.BoolVar(&flags.insecure, "insecure", false, "Forces Task to download Taskfiles over insecure connections.")
 	pflag.BoolVarP(&flags.watch, "watch", "w", false, "Enables watch of the given task.")
 	pflag.BoolVarP(&flags.verbose, "verbose", "v", false, "Enables verbose mode.")
 	pflag.BoolVarP(&flags.silent, "silent", "s", false, "Disables echoing.")
@@ -140,6 +144,12 @@ func run() error {
 		pflag.BoolVarP(&flags.forceAll, "force", "f", false, "Forces execution even when the task is up-to-date.")
 	}
 
+	// Remote Taskfiles experiment will adds the "download" and "offline" flags
+	if experiments.RemoteTaskfiles {
+		pflag.BoolVar(&flags.download, "download", false, "Downloads a cached version of a remote Taskfile.")
+		pflag.BoolVar(&flags.offline, "offline", false, "Forces Task to only use local or cached Taskfiles.")
+	}
+
 	pflag.Parse()
 
 	if flags.version {
@@ -173,6 +183,10 @@ func run() error {
 		return nil
 	}
 
+	if flags.download && flags.offline {
+		return errors.New("task: You can't set both --download and --offline flags")
+	}
+
 	if flags.global && flags.dir != "" {
 		log.Fatal("task: You can't set both --global and --dir")
 		return nil
@@ -216,6 +230,9 @@ func run() error {
 	e := task.Executor{
 		Force:       flags.force,
 		ForceAll:    flags.forceAll,
+		Insecure:    flags.insecure,
+		Download:    flags.download,
+		Offline:     flags.offline,
 		Watch:       flags.watch,
 		Verbose:     flags.verbose,
 		Silent:      flags.silent,
@@ -278,6 +295,13 @@ func run() error {
 		calls, globals = args.ParseV2(tasksAndVars...)
 	}
 
+	// If there are no calls, run the default task instead
+	// Unless the download flag is specified, in which case we want to download
+	// the Taskfile and do nothing else
+	if len(calls) == 0 && !flags.download {
+		calls = append(calls, taskfile.Call{Task: "default", Direct: true})
+	}
+
 	globals.Set("CLI_ARGS", taskfile.Var{Static: cliArgs})
 	e.Taskfile.Vars.Merge(globals)
 

docs/blog/2023-09-02-introducing-experiments.md

@@ -0,0 +1,142 @@
+---
+title: Introducing Experiments
+description:
+  A look at where task is, where it's going and how we're going to get there.
+slug: task-in-2023
+authors: [pd93]
+tags: [experiments, breaking-changes, roadmap, v4]
+image: https://i.imgur.com/mErPwqL.png
+hide_table_of_contents: false
+---
+
+Lately, Task has been growing extremely quickly and I've found myself thinking a
+lot about the future of the project and how we continue to evolve and grow. I'm
+not much of a writer, but I think one of the things we could do better is to
+communicate these kinds of thoughts to the community. So, with that in mind,
+this is the first (hopefully of many) blog posts talking about Task and what
+we're up to.
+
+<!--truncate-->
+
+## :calendar: So, what have we been up to?
+
+Over the past 12 months or so, [@andreynering] (Author and maintainer of the
+project) and I ([@pd93]) have been working in our spare time to maintain and
+improve v3 of Task and we've made some amazing progress. Here are just some of
+the things we've released in that time:
+
+- An official [extension for VS Code][vscode-task].
+- Internal Tasks ([#818](https://github.com/go-task/task/pull/818)).
+- Task aliases ([#879](https://github.com/go-task/task/pull/879)).
+- Looping over tasks ([#1220](https://github.com/go-task/task/pull/1200)).
+- A series of refactors to the core codebase to make it more maintainable and
+  extensible.
+- Loads of bug fixes and improvements.
+- An integration with [Crowdin][crowdin]. Work is in progress on making our docs
+  available in **7 new languages** (Special thanks to all our translators for
+  the huge help with this!).
+- And much, much more! :sparkles:
+
+We're also working on adding some really exciting and highly requested features
+to Task such as having the ability to run remote Taskfiles
+([#1317](https://github.com/go-task/task/issues/1317)).
+
+None of this would have been possible without the [150 or so (and growing)
+contributors][contributors] to the project, numerous sponsors and a passionate
+community of users. Together we have more than doubled the number of GitHub
+stars to over 8400 :star: since the beginning of 2022 and this continues to
+accelerate. We can't thank you all enough for your help and support! :rocket:
+
+[![Star History Chart](https://api.star-history.com/svg?repos=go-task/task&type=Date)](https://star-history.com/#go-task/task&Date)
+
+## What's next? :thinking_face:
+
+It's extremely motivating to see so many people using and loving Task. However,
+in this time we've also seen an increase in the number of issues and feature
+requests. In particular, issues that require some kind of breaking change to
+Task. This isn't a bad thing, but as we grow we need to be more responsible
+about how we address these changes in a way that ensures stability and
+compatibility for existing users and their Taskfiles.
+
+At this point you're probably thinking something like:
+
+> "But you use [semantic versioning][semver] - Just release a new major version
+> with your breaking changes."
+
+And you'd be right... sort of. In theory, this sounds great, but the reality is
+that we don't have the time to commit to a major overhaul of Task in one big
+bang release. This would require a colossal amount of time and coordination and
+with full time jobs and personal lives to tend to, this is a difficult
+commitment to make. Smaller, more frequent major releases are also a significant
+inconvenience for users as they have to constantly keep up-to-date with our
+breaking changes. Fortunately, there is a better way.
+
+## What's going to change? :face_with_monocle:
+
+Going forwards, breaking changes will be allowed into _minor_ versions of Task
+as "experimental features". To access these features users will need opt-in by
+enabling feature flags. This will allow us to release new features slowly and
+gather feedback from the community before making them the default behavior in a
+future major release.
+
+To prepare users for the next major release, we will maintain a list of
+[deprecated features][deprecations] and [experiments][experiments] on our docs
+website and publish information on how to migrate to the new behavior.
+
+You can read the [full breaking change proposal][breaking-change-proposal] and
+view all the [current experiments and their status][experiments-project] on
+GitHub including the [Gentle Force][gentle-force-experiment] and [Remote
+Taskfiles][remote-taskfiles-experiment] experiments.
+
+## What will happen to v2/v3 features?
+
+v2 has been [officially deprecated][deprecate-version-2-schema]. If you're still
+using a Taskfile with `version: "2"` at the top we _strongly recommend_ that you
+upgrade as soon as possible. Removing v2 will allow us to tidy up the codebase
+and focus on new functionality instead.
+
+When v4 is released, we will continue to support v3 for a period of time (bug
+fixes etc). However, since we are moving from a backward-compatibility model to
+a forwards-compatibility model, **v4 itself will not be backwards compatible
+with v3**.
+
+## v4 When? :eyes:
+
+:shrug: When it's ready.
+
+In all seriousness, we don't have a timeline for this yet. We'll be working on
+the most serious deficiencies of the v3 API first and regularly evaluating the
+state of the project. When we feel its in a good, stable place and we have a
+clear upgrade path for users and a number of stable experiments, we'll start to
+think about v4.
+
+## :wave: Final thoughts
+
+Task is growing fast and we're excited to see where it goes next. We hope that
+the steps we're taking to improve the project and our process will help us to
+continue to grow. As always, if you have any questions or feedback, we encourage
+you to comment on or open [issues][issues] and [discussions][discussions] on
+GitHub. Alternatively, you can join us on [Discord][discord].
+
+I plan to write more of these blog posts in the future on a variety of
+Task-related topics, so make sure to check in occasionally and see what we're up
+to!
+
+<!-- prettier-ignore-start -->
+[vscode-task]: https://github.com/go-task/vscode-task
+[crowdin]: https://crowdin.com
+[contributors]: https://github.com/go-task/task/graphs/contributors
+[semver]: https://semver.org
+[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
+[@andreynering]: https://github.com/andreynering
+[@pd93]: https://github.com/pd93
+[experiments]: https://taskfile.dev/experiments
+[deprecations]: https://taskfile.dev/deprecations
+[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
+[issues]: https://github.com/go-task/task/issues
+[discussions]: https://github.com/go-task/task/discussions
+[discord]: https://discord.gg/6TY36E39UK
+[experiments-project]: https://github.com/orgs/go-task/projects/1
+[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
+[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
+<!-- prettier-ignore-end -->

docs/blog/authors.yml

@@ -3,3 +3,8 @@ andreynering:
   title: Maintainer of Task
   url: https://github.com/andreynering
   image_url: https://github.com/andreynering.png
+pd93:
+  name: Pete Davison
+  title: Maintainer of Task
+  url: https://github.com/pd93
+  image_url: https://github.com/pd93.png

docs/docs/changelog.md

@@ -1,16 +1,23 @@
 ---
 slug: /changelog/
-sidebar_position: 9
+sidebar_position: 14
 ---
 
 # Changelog
 
+## v3.30.0 - 2023-09-13
+
+- Prep work for Remote Taskfiles ([#1316](https://github.com/go-task/task/issues/1316) by [@pd93](https://github.com/pd93)).
+- Added the
+  [Remote Taskfiles experiment](https://taskfile.dev/experiments/remote-taskfiles)
+  as a draft ([#1152](https://github.com/go-task/task/issues/1152), [#1317](https://github.com/go-task/task/issues/1317) by [@pd93](https://github.com/pd93)).
+- Improve performance of content checksuming on `sources:` by replacing md5 with
+  [XXH3](https://xxhash.com/) which is much faster. This is a soft breaking
+  change because checksums will be invalidated when upgrading to this release
+  ([#1325](https://github.com/go-task/task/issues/1325) by [@ReillyBrogan](https://github.com/ReillyBrogan)).
+
 ## v3.29.1 - 2023-08-26
 
-- Fix automate release process.
-
-## v3.29.0 - 2023-08-26
-
 - Update to Go 1.21 (bump minimum version to 1.20) ([#1302](https://github.com/go-task/task/issues/1302) by [@pd93](https://github.com/pd93))
 - Fix a missing a line break on log when using `--watch` mode ([#1285](https://github.com/go-task/task/issues/1285), [#1297](https://github.com/go-task/task/issues/1297) by
   [@FilipSolich](https://github.com/FilipSolich)).
@@ -18,8 +25,8 @@ sidebar_position: 9
 - Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in
   combination with `includes` ([#1046](https://github.com/go-task/task/issues/1046), [#1205](https://github.com/go-task/task/issues/1205), [#1250](https://github.com/go-task/task/issues/1250), [#1293](https://github.com/go-task/task/issues/1293), [#1312](https://github.com/go-task/task/issues/1312), [#1274](https://github.com/go-task/task/issues/1274) by
   [@andarto](https://github.com/andarto), [#1309](https://github.com/go-task/task/issues/1309) by [@andreynering](https://github.com/andreynering)).
-- Fix bug on `--status` flag. Running this flag should not have side-effects:
-  it should not update the checksum on `.task`, only report its status ([#1305](https://github.com/go-task/task/issues/1305),
+- Fix bug on `--status` flag. Running this flag should not have side-effects: it
+  should not update the checksum on `.task`, only report its status ([#1305](https://github.com/go-task/task/issues/1305),
   [#1307](https://github.com/go-task/task/issues/1307) by [@visciang](https://github.com/visciang), [#1313](https://github.com/go-task/task/issues/1313) by [@andreynering](https://github.com/andreynering)).
 
 ## v3.28.0 - 2023-07-24
@@ -47,7 +54,8 @@ sidebar_position: 9
 - Bug fixes were made to the
   [npm installation method](https://taskfile.dev/installation/#npm). ([#1190](https://github.com/go-task/task/issues/1190), by
   [@sounisi5011](https://github.com/sounisi5011)).
-- Added the [gentle force experiment](https://taskfile.dev/experiments) as a
+- Added the
+  [gentle force experiment](https://taskfile.dev/experiments/gentle-force) as a
   draft ([#1200](https://github.com/go-task/task/issues/1200), [#1216](https://github.com/go-task/task/issues/1216) by [@pd93](https://github.com/pd93)).
 - Added an `--experiments` flag to allow you to see which experiments are
   enabled ([#1242](https://github.com/go-task/task/issues/1242) by [@pd93](https://github.com/pd93)).

docs/docs/community.md

@@ -1,6 +1,6 @@
 ---
 slug: /community/
-sidebar_position: 10
+sidebar_position: 9
 ---
 
 # Community
@@ -11,7 +11,8 @@ thankful for everyone that helps me to improve the overall experience.
 
 ## Translations
 
-We use [Crowdin](https://crowdin.com/project/taskfile) to translate our document.
+We use [Crowdin](https://crowdin.com/project/taskfile) to translate our
+document.
 
 ## Integrations
 

docs/docs/deprecations/deprecations.md

@@ -0,0 +1,19 @@
+---
+slug: /deprecations/
+sidebar_position: 7
+---
+
+# Deprecations
+
+As Task evolves, it occasionally outgrows some of its functionality. This can be
+because they are no longer useful, because another feature has replaced it or
+because of a change in the way that Task works internally.
+
+When this happens, we mark the functionality as deprecated. This means that it
+will be removed in a future version of Task. This functionality will continue to
+work until that time, but we strongly recommend that you do not implement this
+functionality in new Taskfiles and make a plan to migrate away from it as soon
+as possible.
+
+You can view a full list of active deprecations in the "Deprecations" section of
+the sidebar.

docs/docs/deprecations/template.md

@@ -0,0 +1,18 @@
+---
+# This is a template for an experiments documentation
+# Copy this page and fill in the details as necessary
+title: '--- Template ---'
+sidebar_position: -1 # Always push to the top
+draft: true # Hide in production
+---
+
+# {Name of Deprecated Feature}
+
+- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
+- Breaks:
+  - {list any existing functionality that will be broken by this experiment}
+
+{Short description of the feature/behavior and why it is being deprecated}
+
+{Short explanation of any replacement features/behaviors and how users should
+migrate to it}

docs/docs/deprecations/version_2_schema.md

@@ -0,0 +1,27 @@
+---
+slug: /deprecations/version-2-schema/
+---
+
+# Version 2 Schema
+
+- Issue: [#1197][deprecate-version-2-schema]
+- Breaks:
+  - Any Taskfiles that use the version 2 schema
+  - `Taskvar.yml` files
+
+The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in
+August the following year. Users have had a long time to update and so we feel
+that it is time to tidy up the codebase and focus on new functionality instead.
+
+This notice does not mean that we are immediately removing support for version 2
+schemas. However, support will not be extended to future major releases and we
+_strongly recommend_ that anybody still using a version 2 schema upgrades to
+version 3 as soon as possible.
+
+A list of changes between version 2 and version 3 are available in the [Task v3
+Release Notes][version-3-release-notes].
+
+<!-- prettier-ignore-start -->
+[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
+[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0
+<!-- prettier-ignore-end -->

docs/docs/donate.md

@@ -1,6 +1,6 @@
 ---
 slug: /donate/
-sidebar_position: 15
+sidebar_position: 16
 ---
 
 # Donate

docs/docs/experiments/experiments.md

@@ -1,6 +1,6 @@
 ---
 slug: /experiments/
-sidebar_position: 5
+sidebar_position: 6
 ---
 
 # Experiments
@@ -16,8 +16,11 @@ environment. They are intended for testing and feedback only.
 In order to allow Task to evolve quickly, we roll out breaking changes to minor
 versions behind experimental flags. This allows us to gather feedback on
 breaking changes before committing to a major release. This document describes
-the current set of experimental features and the deprecated feature that they
-are intended to replace.
+the current set of experimental features and their status in the
+[workflow](#workflow).
+
+You can view a full list of active experiments in the "Experiments" section of
+the sidebar.
 
 You can enable an experimental feature by:
 
@@ -42,59 +45,83 @@ flags/environment variables to enable the experiment are and how the feature's
 behavior will change. It will also explain what you need to do to migrate any
 existing Taskfiles to the new behavior.
 
-<!-- EXPERIMENT TEMPLATE - Include sections as necessary...
+## Workflow
 
-### ![experiment] {Feature} ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
+Experiments are a way for us to test out new features in Task before committing
+to them in a major release. Because this concept is built around the idea of
+feedback from our community, we have built a workflow for the process of
+introducing these changes. This ensures that experiments are given the attention
+and time that they need and that we are getting the best possible results out of
+them.
 
-- Environment variable: `TASK_X_{feature}`
-- Deprecates: {list any existing functionality that will be deprecated by this experiment}
-- Breaks: {list any existing functionality that will be broken by this experiment}
+The sections below describe the various stages that an experiment must go
+through from its proposal all the way to being released in a major version of
+Task.
 
-{Short description of the feature}
+### 1. Proposal
 
-{Short explanation of how users should migrate to the new behavior}
+All experimental features start with a proposal in the form of a GitHub issue.
+If the maintainers decide that an issue has enough support and is a breaking
+change or is complex/controversial enough to require user feedback, then the
+issue will be marked with the ![proposal] label. At this point, the issue
+becomes a proposal and a period of consultation begins. During this period, we
+request that users provide feedback on the proposal and how it might effect
+their use of Task. It is up to the discretion of the maintainers to decide how
+long this period lasts.
 
--->
+### 2. Draft
 
-### ![deprecated] Version 2 Schema ([#1197][deprecate-version-2-schema])
+Once a proposal's consultation ends, a contributor may pick up the work and
+begin the initial implementation. Once a PR is opened, the maintainers will
+ensure that it meets the requirements for an experimental feature (i.e. flags
+are in the right format etc) and merge the feature. Once this code is released,
+the status will be updated via the ![draft] label. This indicates that an
+implementation is now available for use in a release and the experiment is open
+for feedback.
 
-The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in
-August the following year. Users have had a long time to update and so we feel
-that it is time to tidy up the codebase and focus on new functionality instead.
+:::note
 
-This notice does not mean that we are immediately removing support for version 2
-schemas. However, support will not be extended to future major releases and we
-_strongly recommend_ that anybody still using a version 2 schema upgrades to
-version 3 as soon as possible.
+During the draft period, major changes to the implementation may be made based
+on the feedback received from users. There are _no stability guarantees_ and
+experimental features may be abandoned _at any time_.
 
-A list of changes between version 2 and version 3 are available in the [Task v3
-Release Notes][version-3-release-notes].
+:::
 
-### ![experiment] Gentle Force ([#1200](https://github.com/go-task/task/issues/1200))
+### 3. Candidate
 
-- Environment variable: `TASK_X_FORCE=1`
-- Breaks: `--force` flag
+Once an acceptable level of consensus has been reached by the community and
+feedback/changes are less frequent/significant, the status may be updated via
+the ![candidate] label. This indicates that a proposal is _likely_ to accepted
+and will enter a period for final comments and minor changes.
 
-The `--force` flag currently forces _all_ tasks to run regardless of the status
-checks. This can be useful, but we have found that most of the time users only
-expect the direct task they are calling to be forced and _not_ all of its
-dependant tasks.
+### 4. Stable
 
-This experiment changes the `--force` flag to only force the directly called
-task. All dependant tasks will have their statuses checked as normal and will
-only run if Task considers them to be out of date. A new `--force-all` flag will
-also be added to maintain the current behavior for users that need this
-functionality.
+Once a suitable amount of time has passed with no changes or feedback, an
+experiment will be given the ![stable] label. At this point, the functionality
+will be treated like any other feature in Task and any changes _must_ be
+backward compatible. This allows users to migrate to the new functionality
+without having to worry about anything breaking in future releases. This
+provides the best experience for users migrating to a new major version.
 
-If you want to migrate, but continue to force all dependant tasks to run, you
-should replace all uses of the `--force` flag with `--force-all`. Alternatively,
-if you want to adopt the new behavior, you can continue to use the `--force`
-flag as you do now!
+### 5. Released
+
+When making a new major release of Task, all experiments marked as ![stable]
+will move to ![released] and their behaviors will become the new default in
+Task. Experiments in an earlier stage (i.e. not stable) cannot be released and
+so will continue to be experiments in the new version.
+
+### Abandoned / Superseded
+
+If an experiment is unsuccessful at any point then it will be given the
+![abandoned] or ![superseded] labels depending on which is more suitable. These
+experiments will be removed from Task.
 
 <!-- prettier-ignore-start -->
-[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
-[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
-[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0
-[deprecated]: https://img.shields.io/badge/deprecated-red
-[experiment]: https://img.shields.io/badge/experiment-yellow
+[proposal]: https://img.shields.io/badge/experiment:%20proposal-purple
+[draft]: https://img.shields.io/badge/experiment:%20draft-purple
+[candidate]: https://img.shields.io/badge/experiment:%20candidate-purple
+[stable]: https://img.shields.io/badge/experiment:%20stable-purple
+[released]: https://img.shields.io/badge/experiment:%20released-purple
+[abandoned]: https://img.shields.io/badge/experiment:%20abandoned-purple
+[superseded]: https://img.shields.io/badge/experiment:%20superseded-purple
 <!-- prettier-ignore-end -->

docs/docs/experiments/gentle_force.md

@@ -0,0 +1,30 @@
+---
+slug: /experiments/gentle-force/
+---
+
+# Gentle Force
+
+- Issue: [#1200][gentle-force-experiment]
+- Environment variable: `TASK_X_FORCE=1`
+- Breaks:
+  - `--force` flag
+
+The `--force` flag currently forces _all_ tasks to run regardless of the status
+checks. This can be useful, but we have found that most of the time users only
+expect the direct task they are calling to be forced and _not_ all of its
+dependant tasks.
+
+This experiment changes the `--force` flag to only force the directly called
+task. All dependant tasks will have their statuses checked as normal and will
+only run if Task considers them to be out of date. A new `--force-all` flag will
+also be added to maintain the current behavior for users that need this
+functionality.
+
+If you want to migrate, but continue to force all dependant tasks to run, you
+should replace all uses of the `--force` flag with `--force-all`. Alternatively,
+if you want to adopt the new behavior, you can continue to use the `--force`
+flag as you do now!
+
+<!-- prettier-ignore-start -->
+[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
+<!-- prettier-ignore-end -->

docs/docs/experiments/remote_taskfiles.md

@@ -0,0 +1,81 @@
+---
+slug: /experiments/remote-taskfiles/
+---
+
+# Remote Taskfiles
+
+- Issue: [#1317][remote-taskfiles-experiment]
+- Environment variable: `TASK_X_REMOTE_TASKFILES=1`
+
+This experiment allows you to specify a remote Taskfile URL when including a
+Taskfile. For example:
+
+```yaml
+version: '3'
+
+include:
+  my-remote-namespace: https://raw.githubusercontent.com/my-org/my-repo/main/Taskfile.yml
+```
+
+This works exactly the same way that including a local file does. Any tasks in
+the remote Taskfile will be available to run from your main Taskfile via the
+namespace `my-remote-namespace`. For example, if the remote file contains the
+following:
+
+```yaml
+version: '3'
+
+tasks:
+  hello:
+    silent: true
+    cmds:
+      - echo "Hello from the remote Taskfile!"
+```
+
+and you run `task my-remote-namespace:hello`, it will print the text: "Hello
+from the remote Taskfile!" to your console.
+
+## Security
+
+Running commands from sources that you do not control is always a potential
+security risk. For this reason, we have added some checks when using remote
+Taskfiles:
+
+1. When running a task from a remote Taskfile for the first time, Task will
+   print a warning to the console asking you to check that you are sure that you
+   trust the source of the Taskfile. If you do not accept the prompt, then Task
+   will exit with code `104` (not trusted) and nothing will run. If you accept
+   the prompt, the remote Taskfile will run and further calls to the remote
+   Taskfile will not prompt you again.
+2. Whenever you run a remote Taskfile, Task will create and store a checksum of
+   the file that you are running. If the checksum changes, then Task will print
+   another warning to the console to inform you that the contents of the remote
+   file has changed. If you do not accept the prompt, then Task will exit with
+   code `104` (not trusted) and nothing will run. If you accept the prompt, the
+   checksum will be updated and the remote Taskfile will run.
+
+Task currently supports both `http` and `https` URLs. However, the `http`
+requests will not execute by default unless you run the task with the
+`--insecure` flag. This is to protect you from accidentally running a remote
+Taskfile that is hosted on and unencrypted connection. Sources that are not
+protected by TLS are vulnerable to [man-in-the-middle
+attacks][man-in-the-middle-attacks] and should be avoided unless you know what
+you are doing.
+
+## Caching & Running Offline
+
+If for whatever reason, you don't have access to the internet, but you still
+need to be able to run your tasks, you are able to use the `--download` flag to
+store a cached copy of the remote Taskfile.
+
+<!-- TODO: The following behavior may change -->
+
+If Task detects that you have a local copy of the remote Taskfile, it will use
+your local copy instead of downloading the remote file. You can force Task to
+work offline by using the `--offline` flag. This will prevent Task from making
+any calls to remote sources.
+
+<!-- prettier-ignore-start -->
+[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
+[man-in-the-middle-attacks]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack
+<!-- prettier-ignore-end -->

docs/docs/experiments/template.md

@@ -0,0 +1,20 @@
+---
+# This is a template for an experiments documentation
+# Copy this page and fill in the details as necessary
+title: '--- Template ---'
+sidebar_position: -1 # Always push to the top
+draft: true # Hide in production
+---
+
+# {Name of Experiment}
+
+- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
+- Environment variable: `TASK_X_{feature}`
+- Breaks:
+  - {list any existing functionality that will be broken by this experiment}
+- Deprecations:
+  - {link to any deprecation pages related to this experiment}
+
+{Short description of the feature}
+
+{Short explanation of how users should migrate to the new behavior}

docs/docs/experiments/workflow.md

@@ -1,84 +0,0 @@
----
-slug: /experiments/workflow/
----
-
-# Workflow
-
-Experiments are a way for us to test out new features in Task before committing
-to them in a major release. Because this concept is built around the idea of
-feedback from our community, we have built a workflow for the process of
-introducing these changes. This ensures that experiments are given the attention
-and time that they need and that we are getting the best possible results out of
-them.
-
-The sections below describe the various stages that an experiment must go
-through from its proposal all the way to being released in a major version of
-Task.
-
-## 1. Proposal
-
-All experimental features start with a proposal in the form of a GitHub issue.
-If the maintainers decide that an issue has enough support and is a breaking
-change or is complex/controversial enough to require user feedback, then the
-issue will be marked with the ![proposal] label. At this point, the issue
-becomes a proposal and a period of consultation begins. During this period, we
-request that users provide feedback on the proposal and how it might effect
-their use of Task. It is up to the discretion of the maintainers to decide how
-long this period lasts.
-
-## 2. Draft
-
-Once a proposal's consultation ends, a contributor may pick up the work and
-begin the initial implementation. Once a PR is opened, the maintainers will
-ensure that it meets the requirements for an experimental feature (i.e. flags
-are in the right format etc) and merge the feature. Once this code is released,
-the status will be updated via the ![draft] label. This indicates that an
-implementation is now available for use in a release and the experiment is open
-for feedback.
-
-:::note
-
-During the draft period, major changes to the implementation may be made based
-on the feedback received from users. There are _no stability guarantees_ and
-experimental features may be abandoned _at any time_.
-
-:::
-
-## 3. Candidate
-
-Once an acceptable level of consensus has been reached by the community and
-feedback/changes are less frequent/significant, the status may be updated via
-the ![candidate] label. This indicates that a proposal is _likely_ to accepted
-and will enter a period for final comments and minor changes.
-
-## 4. Stable
-
-Once a suitable amount of time has passed with no changes or feedback, an
-experiment will be given the ![stable] label. At this point, the functionality
-will be treated like any other feature in Task and any changes _must_ be
-backward compatible. This allows users to migrate to the new functionality
-without having to worry about anything breaking in future releases. This
-provides the best experience for users migrating to a new major version.
-
-## 5. Released
-
-When making a new major release of Task, all experiments marked as ![stable]
-will move to ![released] and their behaviors will become the new default in
-Task. Experiments in an earlier stage (i.e. not stable) cannot be released and
-so will continue to be experiments in the new version.
-
-## Abandoned / Superseded
-
-If an experiment is unsuccessful at any point then it will be given the
-![abandoned] or ![superseded] labels depending on which is more suitable. These
-experiments will be removed from Task.
-
-<!-- prettier-ignore-start -->
-[proposal]: https://img.shields.io/badge/experiment:%20proposal-purple
-[draft]: https://img.shields.io/badge/experiment:%20draft-purple
-[candidate]: https://img.shields.io/badge/experiment:%20candidate-purple
-[stable]: https://img.shields.io/badge/experiment:%20stable-purple
-[released]: https://img.shields.io/badge/experiment:%20released-purple
-[abandoned]: https://img.shields.io/badge/experiment:%20abandoned-purple
-[superseded]: https://img.shields.io/badge/experiment:%20superseded-purple
-<!-- prettier-ignore-end -->

docs/docs/faq.md

@@ -1,6 +1,6 @@
 ---
 slug: /faq/
-sidebar_position: 7
+sidebar_position: 15
 ---
 
 # FAQ

docs/docs/integrations.md

@@ -1,6 +1,6 @@
 ---
 slug: /integrations/
-sidebar_position: 6
+sidebar_position: 8
 ---
 
 # Integrations

docs/docs/releasing.md

@@ -37,6 +37,15 @@ version:
 - Moving both `amd64`, `armhf` and `arm64` new artifacts to the stable channel
   on the [Snapcraft dashboard][snapcraftdashboard].
 
+# winget
+
+winget also requires manual steps to be completed. By running
+`task test-release` locally, manifest files will be generated on
+`dist/winget/manifests/t/Task/Task/v{version}`.
+[Upload the manifest directory into this fork](https://github.com/go-task/winget-pkgs/tree/master/manifests/t/Task/Task)
+and open a pull request into
+[this repository](https://github.com/microsoft/winget-pkgs).
+
 # Scoop
 
 Scoop is a command-line package manager for the Windows operating system. Scoop

docs/docs/styleguide.md

@@ -1,6 +1,6 @@
 ---
 slug: /styleguide/
-sidebar_position: 8
+sidebar_position: 10
 ---
 
 # Styleguide

docs/docs/taskfile_versions.md

@@ -1,6 +1,6 @@
 ---
 slug: /taskfile-versions/
-sidebar_position: 14
+sidebar_position: 5
 ---
 
 # Taskfile Versions
@@ -29,7 +29,7 @@ These are some major changes done on `v3`:
 - A global `method:` was added to allow setting the default method, and Task's
   default changed to `checksum`
 - Two magic variables were added when using `status:`: `CHECKSUM` and
-  `TIMESTAMP` which contains, respectively, the md5 checksum and greatest
+  `TIMESTAMP` which contains, respectively, the XXH3 checksum and greatest
   modification timestamp of the files listed on `sources:`
 - Also, the `TASK` variable is always available with the current task name
 - CLI variables are always treated as global variables

docs/docusaurus.config.js

@@ -94,7 +94,7 @@ const getConfig = async () => {
             routeBasePath: '/',
             sidebarPath: require.resolve('./sidebars.js')
           },
-          blog: false,
+          blog: {},
           theme: {
             customCss: [
               require.resolve('./src/css/custom.css'),
@@ -155,6 +155,11 @@ const getConfig = async () => {
               position: 'left',
               label: 'API'
             },
+            {
+              to: 'blog',
+              label: 'Blog',
+              position: 'left'
+            },
             {
               type: 'doc',
               docId: 'donate',

docs/i18n/es-ES/docusaurus-plugin-content-blog/2023-09-02-introducing-experiments.md

@@ -0,0 +1,93 @@
+---
+title: Introducing Experiments
+description: A look at where task is, where it's going and how we're going to get there.
+slug: task-in-2023
+authors:
+  - pd93
+tags:
+  - experiments
+  - breaking-changes
+  - roadmap
+  - v4
+image: https://i.imgur.com/mErPwqL.png
+hide_table_of_contents: false
+---
+
+Lately, Task has been growing extremely quickly and I've found myself thinking a lot about the future of the project and how we continue to evolve and grow. I'm not much of a writer, but I think one of the things we could do better is to communicate these kinds of thoughts to the community. So, with that in mind, this is the first (hopefully of many) blog posts talking about Task and what we're up to.
+
+<!--truncate-->
+
+## :calendar: So, what have we been up to?
+
+Over the past 12 months or so, [@andreynering][] (Author and maintainer of the project) and I ([@pd93][]) have been working in our spare time to maintain and improve v3 of Task and we've made some amazing progress. Here are just some of the things we've released in that time:
+
+- An official [extension for VS Code][vscode-task].
+- Internal Tasks ([#818](https://github.com/go-task/task/pull/818)).
+- Task aliases ([#879](https://github.com/go-task/task/pull/879)).
+- Looping over tasks ([#1220](https://github.com/go-task/task/pull/1200)).
+- A series of refactors to the core codebase to make it more maintainable and extensible.
+- Loads of bug fixes and improvements.
+- An integration with [Crowdin][crowdin]. Work is in progress on making our docs available in **7 new languages** (Special thanks to all our translators for the huge help with this!).
+- And much, much more! :sparkles:
+
+We're also working on adding some really exciting and highly requested features to Task such as having the ability to run remote Taskfiles ([#1317](https://github.com/go-task/task/issues/1317)).
+
+None of this would have been possible without the [150 or so (and growing) contributors][contributors] to the project, numerous sponsors and a passionate community of users. Together we have more than doubled the number of GitHub stars to over 8400 :star: since the beginning of 2022 and this continues to accelerate. We can't thank you all enough for your help and support! :rocket:
+
+[![Star History Chart](https://api.star-history.com/svg?repos=go-task/task&type=Date)](https://star-history.com/#go-task/task&Date)
+
+## What's next? :thinking_face:
+
+It's extremely motivating to see so many people using and loving Task. However, in this time we've also seen an increase in the number of issues and feature requests. In particular, issues that require some kind of breaking change to Task. This isn't a bad thing, but as we grow we need to be more responsible about how we address these changes in a way that ensures stability and compatibility for existing users and their Taskfiles.
+
+At this point you're probably thinking something like:
+
+> "But you use [semantic versioning][semver] - Just release a new major version with your breaking changes."
+
+And you'd be right... sort of. In theory, this sounds great, but the reality is that we don't have the time to commit to a major overhaul of Task in one big bang release. This would require a colossal amount of time and coordination and with full time jobs and personal lives to tend to, this is a difficult commitment to make. Smaller, more frequent major releases are also a significant inconvenience for users as they have to constantly keep up-to-date with our breaking changes. Fortunately, there is a better way.
+
+## What's going to change? :face_with_monocle:
+
+Going forwards, breaking changes will be allowed into _minor_ versions of Task as "experimental features". To access these features users will need opt-in by enabling feature flags. This will allow us to release new features slowly and gather feedback from the community before making them the default behavior in a future major release.
+
+To prepare users for the next major release, we will maintain a list of [deprecated features][deprecations] and [experiments][experiments] on our docs website and publish information on how to migrate to the new behavior.
+
+You can read the [full breaking change proposal][breaking-change-proposal] and view all the [current experiments and their status][experiments-project] on GitHub including the [Gentle Force][gentle-force-experiment] and [Remote Taskfiles][remote-taskfiles-experiment] experiments.
+
+## What will happen to v2/v3 features?
+
+v2 has been [officially deprecated][deprecate-version-2-schema]. If you're still using a Taskfile with `version: "2"` at the top we _strongly recommend_ that you upgrade as soon as possible. Removing v2 will allow us to tidy up the codebase and focus on new functionality instead.
+
+When v4 is released, we will continue to support v3 for a period of time (bug fixes etc). However, since we are moving from a backward-compatibility model to a forwards-compatibility model, **v4 itself will not be backwards compatible with v3**.
+
+## v4 When? :eyes:
+
+:shrug: When it's ready.
+
+In all seriousness, we don't have a timeline for this yet. We'll be working on the most serious deficiencies of the v3 API first and regularly evaluating the state of the project. When we feel its in a good, stable place and we have a clear upgrade path for users and a number of stable experiments, we'll start to think about v4.
+
+## :wave: Final thoughts
+
+Task is growing fast and we're excited to see where it goes next. We hope that the steps we're taking to improve the project and our process will help us to continue to grow. As always, if you have any questions or feedback, we encourage you to comment on or open [issues][issues] and [discussions][discussions] on GitHub. Alternatively, you can join us on [Discord][discord].
+
+I plan to write more of these blog posts in the future on a variety of Task-related topics, so make sure to check in occasionally and see what we're up to!
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[vscode-task]: https://github.com/go-task/vscode-task
+[crowdin]: https://crowdin.com
+[contributors]: https://github.com/go-task/task/graphs/contributors
+[semver]: https://semver.org
+[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
+[@andreynering]: https://github.com/andreynering
+[@pd93]: https://github.com/pd93
+[experiments]: https://taskfile.dev/experiments
+[deprecations]: https://taskfile.dev/deprecations
+[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
+[issues]: https://github.com/go-task/task/issues
+[discussions]: https://github.com/go-task/task/discussions
+[discord]: https://discord.gg/6TY36E39UK
+[experiments-project]: https://github.com/orgs/go-task/projects/1
+[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
+[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317

docs/i18n/es-ES/docusaurus-plugin-content-blog/authors.yml

@@ -3,3 +3,8 @@ andreynering:
   title: Maintainer of Task
   url: https://github.com/andreynering
   image_url: https://github.com/andreynering.png
+pd93:
+  name: Pete Davison
+  title: Maintainer of Task
+  url: https://github.com/pd93
+  image_url: https://github.com/pd93.png

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/changelog.md

@@ -1,10 +1,18 @@
 ---
 slug: /changelog/
-sidebar_position: 9
+sidebar_position: 14
 ---
 
 # Changelog
 
+## v3.29.1 - 2023-08-26
+
+- Update to Go 1.21 (bump minimum version to 1.20) ([#1302](https://github.com/go-task/task/issues/1302) by [@pd93](https://github.com/pd93))
+- Fix a missing a line break on log when using `--watch` mode ([#1285](https://github.com/go-task/task/issues/1285), [#1297](https://github.com/go-task/task/issues/1297) by [@FilipSolich](https://github.com/FilipSolich)).
+- Fix `defer` on JSON Schema ([#1288](https://github.com/go-task/task/issues/1288) by [@calvinmclean](https://github.com/calvinmclean) and [@andreynering](https://github.com/andreynering)).
+- Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in combination with `includes` ([#1046](https://github.com/go-task/task/issues/1046), [#1205](https://github.com/go-task/task/issues/1205), [#1250](https://github.com/go-task/task/issues/1250), [#1293](https://github.com/go-task/task/issues/1293), [#1312](https://github.com/go-task/task/issues/1312), [#1274](https://github.com/go-task/task/issues/1274) by [@andarto](https://github.com/andarto), [#1309](https://github.com/go-task/task/issues/1309) by [@andreynering](https://github.com/andreynering)).
+- Fix bug on `--status` flag. Running this flag should not have side-effects: it should not update the checksum on `.task`, only report its status ([#1305](https://github.com/go-task/task/issues/1305), [#1307](https://github.com/go-task/task/issues/1307) by [@visciang](https://github.com/visciang), [#1313](https://github.com/go-task/task/issues/1313) by [@andreynering](https://github.com/andreynering)).
+
 ## v3.28.0 - 2023-07-24
 
 - Added the ability to [loop over commands and tasks](https://taskfile.dev/usage/#looping-over-values) using `for` ([#82](https://github.com/go-task/task/issues/82), [#1220](https://github.com/go-task/task/issues/1220) by [@pd93](https://github.com/pd93)).

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/community.md

@@ -1,6 +1,6 @@
 ---
 slug: /community/
-sidebar_position: 10
+sidebar_position: 9
 ---
 
 # Community

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/deprecations/deprecations.md

@@ -0,0 +1,12 @@
+---
+slug: /deprecations/
+sidebar_position: 7
+---
+
+# Deprecations
+
+As Task evolves, it occasionally outgrows some of its functionality. This can be because they are no longer useful, because another feature has replaced it or because of a change in the way that Task works internally.
+
+When this happens, we mark the functionality as deprecated. This means that it will be removed in a future version of Task. This functionality will continue to work until that time, but we strongly recommend that you do not implement this functionality in new Taskfiles and make a plan to migrate away from it as soon as possible.
+
+You can view a full list of active deprecations in the "Deprecations" section of the sidebar.

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/deprecations/template.md

@@ -0,0 +1,17 @@
+---
+#This is a template for an experiments documentation
+#Copy this page and fill in the details as necessary
+title: '--- Template ---'
+sidebar_position: -1 #Always push to the top
+draft: true #Hide in production
+---
+
+# {Name of Deprecated Feature}
+
+- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
+- Breaks:
+  - {list any existing functionality that will be broken by this experiment}
+
+{Short description of the feature/behavior and why it is being deprecated}
+
+{Short explanation of any replacement features/behaviors and how users should migrate to it}

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/deprecations/version_2_schema.md

@@ -0,0 +1,22 @@
+---
+slug: /deprecations/version-2-schema/
+---
+
+# Version 2 Schema
+
+- Issue: [#1197][deprecate-version-2-schema]
+- Breaks:
+  - Any Taskfiles that use the version 2 schema
+  - `Taskvar.yml` files
+
+The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
+
+This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
+
+A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
+[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/donate.md

@@ -1,6 +1,6 @@
 ---
 slug: /donate/
-sidebar_position: 15
+sidebar_position: 16
 ---
 
 # Donate

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/experiments/experiments.md

@@ -1,6 +1,6 @@
 ---
 slug: /experiments/
-sidebar_position: 5
+sidebar_position: 6
 ---
 
 # Experiments
@@ -11,7 +11,9 @@ All experimental features are subject to breaking changes and/or removal _at any
 
 :::
 
-In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and the deprecated feature that they are intended to replace.
+In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and their status in the [workflow](#workflow).
+
+You can view a full list of active experiments in the "Experiments" section of the sidebar.
 
 You can enable an experimental feature by:
 
@@ -28,43 +30,49 @@ TASK_X_FEATURE=1
 
 Each section below details an experiment or deprecation and explains what the flags/environment variables to enable the experiment are and how the feature's behavior will change. It will also explain what you need to do to migrate any existing Taskfiles to the new behavior.
 
-<!-- EXPERIMENT TEMPLATE - Include sections as necessary...
+## Workflow
 
-### ![experiment] {Feature} ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
+Experiments are a way for us to test out new features in Task before committing to them in a major release. Because this concept is built around the idea of feedback from our community, we have built a workflow for the process of introducing these changes. This ensures that experiments are given the attention and time that they need and that we are getting the best possible results out of them.
 
-- Environment variable: `TASK_X_{feature}`
-- Deprecates: {list any existing functionality that will be deprecated by this experiment}
-- Breaks: {list any existing functionality that will be broken by this experiment}
+The sections below describe the various stages that an experiment must go through from its proposal all the way to being released in a major version of Task.
 
-{Short description of the feature}
+### 1. Proposal
 
-{Short explanation of how users should migrate to the new behavior}
+All experimental features start with a proposal in the form of a GitHub issue. If the maintainers decide that an issue has enough support and is a breaking change or is complex/controversial enough to require user feedback, then the issue will be marked with the ![proposal][] label. At this point, the issue becomes a proposal and a period of consultation begins. During this period, we request that users provide feedback on the proposal and how it might effect their use of Task. It is up to the discretion of the maintainers to decide how long this period lasts.
 
--->
+### 2. Draft
 
-### ![deprecated][] Version 2 Schema ([#1197][deprecate-version-2-schema])
+Once a proposal's consultation ends, a contributor may pick up the work and begin the initial implementation. Once a PR is opened, the maintainers will ensure that it meets the requirements for an experimental feature (i.e. flags are in the right format etc) and merge the feature. Once this code is released, the status will be updated via the ![draft][] label. This indicates that an implementation is now available for use in a release and the experiment is open for feedback.
 
-The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
+:::note
 
-This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
+During the draft period, major changes to the implementation may be made based on the feedback received from users. There are _no stability guarantees_ and experimental features may be abandoned _at any time_.
 
-A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
+:::
 
-### ![experiment][] Gentle Force ([#1200](https://github.com/go-task/task/issues/1200))
+### 3. Candidate
 
-- Environment variable: `TASK_X_FORCE=1`
-- Breaks: `--force` flag
+Once an acceptable level of consensus has been reached by the community and feedback/changes are less frequent/significant, the status may be updated via the ![candidate][] label. This indicates that a proposal is _likely_ to accepted and will enter a period for final comments and minor changes.
 
-The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
+### 4. Stable
 
-This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
+Once a suitable amount of time has passed with no changes or feedback, an experiment will be given the ![stable][] label. At this point, the functionality will be treated like any other feature in Task and any changes _must_ be backward compatible. This allows users to migrate to the new functionality without having to worry about anything breaking in future releases. This provides the best experience for users migrating to a new major version.
 
-If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
+### 5. Released
+
+When making a new major release of Task, all experiments marked as ![stable][] will move to ![released][] and their behaviors will become the new default in Task. Experiments in an earlier stage (i.e. not stable) cannot be released and so will continue to be experiments in the new version.
+
+### Abandoned / Superseded
+
+If an experiment is unsuccessful at any point then it will be given the ![abandoned][] or ![superseded][] labels depending on which is more suitable. These experiments will be removed from Task.
 
 <!-- prettier-ignore-start -->
 
 <!-- prettier-ignore-end -->
-[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
-[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0
-[deprecated]: https://img.shields.io/badge/deprecated-red
-[experiment]: https://img.shields.io/badge/experiment-yellow
+[proposal]: https://img.shields.io/badge/experiment:%20proposal-purple
+[draft]: https://img.shields.io/badge/experiment:%20draft-purple
+[candidate]: https://img.shields.io/badge/experiment:%20candidate-purple
+[stable]: https://img.shields.io/badge/experiment:%20stable-purple
+[released]: https://img.shields.io/badge/experiment:%20released-purple
+[abandoned]: https://img.shields.io/badge/experiment:%20abandoned-purple
+[superseded]: https://img.shields.io/badge/experiment:%20superseded-purple

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/experiments/gentle_force.md

@@ -0,0 +1,21 @@
+---
+slug: /experiments/gentle-force/
+---
+
+# Gentle Force
+
+- Issue: [#1200][gentle-force-experiment]
+- Environment variable: `TASK_X_FORCE=1`
+- Breaks:
+  - `--force` flag
+
+The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
+
+This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
+
+If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[gentle-force-experiment]: https://github.com/go-task/task/issues/1200

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/experiments/remote_taskfiles.md

@@ -0,0 +1,54 @@
+---
+slug: /experiments/remote-taskfiles/
+---
+
+# Remote Taskfiles
+
+- Issue: [#1317][remote-taskfiles-experiment]
+- Environment variable: `TASK_X_REMOTE_TASKFILES=1`
+
+This experiment allows you to specify a remote Taskfile URL when including a Taskfile. For example:
+
+```yaml
+version: '3'
+
+include:
+  my-remote-namespace: https://raw.githubusercontent.com/my-org/my-repo/main/Taskfile.yml
+```
+
+This works exactly the same way that including a local file does. Any tasks in the remote Taskfile will be available to run from your main Taskfile via the namespace `my-remote-namespace`. For example, if the remote file contains the following:
+
+```yaml
+version: '3'
+
+tasks:
+  hello:
+    silent: true
+    cmds:
+      - echo "Hello from the remote Taskfile!"
+```
+
+and you run `task my-remote-namespace:hello`, it will print the text: "Hello from the remote Taskfile!" to your console.
+
+## Security
+
+Running commands from sources that you do not control is always a potential security risk. For this reason, we have added some checks when using remote Taskfiles:
+
+1. When running a task from a remote Taskfile for the first time, Task will print a warning to the console asking you to check that you are sure that you trust the source of the Taskfile. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the remote Taskfile will run and further calls to the remote Taskfile will not prompt you again.
+2. Whenever you run a remote Taskfile, Task will create and store a checksum of the file that you are running. If the checksum changes, then Task will print another warning to the console to inform you that the contents of the remote file has changed. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the checksum will be updated and the remote Taskfile will run.
+
+Task currently supports both `http` and `https` URLs. However, the `http` requests will not execute by default unless you run the task with the `--insecure` flag. This is to protect you from accidentally running a remote Taskfile that is hosted on and unencrypted connection. Sources that are not protected by TLS are vulnerable to [man-in-the-middle attacks][man-in-the-middle-attacks] and should be avoided unless you know what you are doing.
+
+## Caching & Running Offline
+
+If for whatever reason, you don't have access to the internet, but you still need to be able to run your tasks, you are able to use the `--download` flag to store a cached copy of the remote Taskfile.
+
+<!-- TODO: The following behavior may change -->
+
+If Task detects that you have a local copy of the remote Taskfile, it will use your local copy instead of downloading the remote file. You can force Task to work offline by using the `--offline` flag. This will prevent Task from making any calls to remote sources.
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
+[man-in-the-middle-attacks]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/experiments/template.md

@@ -0,0 +1,20 @@
+---
+#This is a template for an experiments documentation
+#Copy this page and fill in the details as necessary
+title: '--- Template ---'
+sidebar_position: -1 #Always push to the top
+draft: true #Hide in production
+---
+
+# {Name of Experiment}
+
+- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
+- Environment variable: `TASK_X_{feature}`
+- Breaks:
+  - {list any existing functionality that will be broken by this experiment}
+- Deprecations:
+  - {link to any deprecation pages related to this experiment}
+
+{Short description of the feature}
+
+{Short explanation of how users should migrate to the new behavior}

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/faq.md

@@ -1,6 +1,6 @@
 ---
 slug: /faq/
-sidebar_position: 7
+sidebar_position: 15
 ---
 
 # FAQ

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/integrations.md

@@ -1,6 +1,6 @@
 ---
 slug: /integrations/
-sidebar_position: 6
+sidebar_position: 8
 ---
 
 # Integrations

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/releasing.md

@@ -26,6 +26,10 @@ The [snap package][snappackage] requires to manual steps to release a new versio
 - Updating the current version on [snapcraft.yaml][snapcraftyaml].
 - Moving both `amd64`, `armhf` and `arm64` new artifacts to the stable channel on the [Snapcraft dashboard][snapcraftdashboard].
 
+# winget
+
+winget also requires manual steps to be completed. By running `task test-release` locally, manifest files will be generated on `dist/winget/manifests/t/Task/Task/v{version}`. [Upload the manifest directory into this fork](https://github.com/go-task/winget-pkgs/tree/master/manifests/t/Task/Task) and open a pull request into [this repository](https://github.com/microsoft/winget-pkgs).
+
 # Scoop
 
 Scoop is a command-line package manager for the Windows operating system. Scoop package manifests are maintained by the community. Scoop owners usually take care of updating versions there by editing [this file](https://github.com/ScoopInstaller/Main/blob/master/bucket/task.json). If you think its Task version is outdated, open an issue to let us know.

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/styleguide.md

@@ -1,6 +1,6 @@
 ---
 slug: /styleguide/
-sidebar_position: 8
+sidebar_position: 10
 ---
 
 # Styleguide

docs/i18n/es-ES/docusaurus-plugin-content-docs/current/taskfile_versions.md

@@ -1,6 +1,6 @@
 ---
 slug: /taskfile-versions/
-sidebar_position: 14
+sidebar_position: 5
 ---
 
 # Taskfile Versions
@@ -21,7 +21,7 @@ These are some major changes done on `v3`:
 - Added support for `.env` like files
 - Added `label:` setting to task so one can override how the task name appear in the logs
 - A global `method:` was added to allow setting the default method, and Task's default changed to `checksum`
-- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the md5 checksum and greatest modification timestamp of the files listed on `sources:`
+- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the XXH3 checksum and greatest modification timestamp of the files listed on `sources:`
 - Also, the `TASK` variable is always available with the current task name
 - CLI variables are always treated as global variables
 - Added `dir:` option to `includes` to allow choosing on which directory an included Taskfile will run:

docs/i18n/fr-FR/docusaurus-plugin-content-blog/2023-09-02-introducing-experiments.md

@@ -0,0 +1,93 @@
+---
+title: Introducing Experiments
+description: A look at where task is, where it's going and how we're going to get there.
+slug: task-in-2023
+authors:
+  - pd93
+tags:
+  - experiments
+  - breaking-changes
+  - roadmap
+  - v4
+image: https://i.imgur.com/mErPwqL.png
+hide_table_of_contents: false
+---
+
+Lately, Task has been growing extremely quickly and I've found myself thinking a lot about the future of the project and how we continue to evolve and grow. I'm not much of a writer, but I think one of the things we could do better is to communicate these kinds of thoughts to the community. So, with that in mind, this is the first (hopefully of many) blog posts talking about Task and what we're up to.
+
+<!--truncate-->
+
+## :calendar: So, what have we been up to?
+
+Over the past 12 months or so, [@andreynering][] (Author and maintainer of the project) and I ([@pd93][]) have been working in our spare time to maintain and improve v3 of Task and we've made some amazing progress. Here are just some of the things we've released in that time:
+
+- An official [extension for VS Code][vscode-task].
+- Internal Tasks ([#818](https://github.com/go-task/task/pull/818)).
+- Task aliases ([#879](https://github.com/go-task/task/pull/879)).
+- Looping over tasks ([#1220](https://github.com/go-task/task/pull/1200)).
+- A series of refactors to the core codebase to make it more maintainable and extensible.
+- Loads of bug fixes and improvements.
+- An integration with [Crowdin][crowdin]. Work is in progress on making our docs available in **7 new languages** (Special thanks to all our translators for the huge help with this!).
+- And much, much more! :sparkles:
+
+We're also working on adding some really exciting and highly requested features to Task such as having the ability to run remote Taskfiles ([#1317](https://github.com/go-task/task/issues/1317)).
+
+None of this would have been possible without the [150 or so (and growing) contributors][contributors] to the project, numerous sponsors and a passionate community of users. Together we have more than doubled the number of GitHub stars to over 8400 :star: since the beginning of 2022 and this continues to accelerate. We can't thank you all enough for your help and support! :rocket:
+
+[![Star History Chart](https://api.star-history.com/svg?repos=go-task/task&type=Date)](https://star-history.com/#go-task/task&Date)
+
+## What's next? :thinking_face:
+
+It's extremely motivating to see so many people using and loving Task. However, in this time we've also seen an increase in the number of issues and feature requests. In particular, issues that require some kind of breaking change to Task. This isn't a bad thing, but as we grow we need to be more responsible about how we address these changes in a way that ensures stability and compatibility for existing users and their Taskfiles.
+
+At this point you're probably thinking something like:
+
+> "But you use [semantic versioning][semver] - Just release a new major version with your breaking changes."
+
+And you'd be right... sort of. In theory, this sounds great, but the reality is that we don't have the time to commit to a major overhaul of Task in one big bang release. This would require a colossal amount of time and coordination and with full time jobs and personal lives to tend to, this is a difficult commitment to make. Smaller, more frequent major releases are also a significant inconvenience for users as they have to constantly keep up-to-date with our breaking changes. Fortunately, there is a better way.
+
+## What's going to change? :face_with_monocle:
+
+Going forwards, breaking changes will be allowed into _minor_ versions of Task as "experimental features". To access these features users will need opt-in by enabling feature flags. This will allow us to release new features slowly and gather feedback from the community before making them the default behavior in a future major release.
+
+To prepare users for the next major release, we will maintain a list of [deprecated features][deprecations] and [experiments][experiments] on our docs website and publish information on how to migrate to the new behavior.
+
+You can read the [full breaking change proposal][breaking-change-proposal] and view all the [current experiments and their status][experiments-project] on GitHub including the [Gentle Force][gentle-force-experiment] and [Remote Taskfiles][remote-taskfiles-experiment] experiments.
+
+## What will happen to v2/v3 features?
+
+v2 has been [officially deprecated][deprecate-version-2-schema]. If you're still using a Taskfile with `version: "2"` at the top we _strongly recommend_ that you upgrade as soon as possible. Removing v2 will allow us to tidy up the codebase and focus on new functionality instead.
+
+When v4 is released, we will continue to support v3 for a period of time (bug fixes etc). However, since we are moving from a backward-compatibility model to a forwards-compatibility model, **v4 itself will not be backwards compatible with v3**.
+
+## v4 When? :eyes:
+
+:shrug: When it's ready.
+
+In all seriousness, we don't have a timeline for this yet. We'll be working on the most serious deficiencies of the v3 API first and regularly evaluating the state of the project. When we feel its in a good, stable place and we have a clear upgrade path for users and a number of stable experiments, we'll start to think about v4.
+
+## :wave: Final thoughts
+
+Task is growing fast and we're excited to see where it goes next. We hope that the steps we're taking to improve the project and our process will help us to continue to grow. As always, if you have any questions or feedback, we encourage you to comment on or open [issues][issues] and [discussions][discussions] on GitHub. Alternatively, you can join us on [Discord][discord].
+
+I plan to write more of these blog posts in the future on a variety of Task-related topics, so make sure to check in occasionally and see what we're up to!
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[vscode-task]: https://github.com/go-task/vscode-task
+[crowdin]: https://crowdin.com
+[contributors]: https://github.com/go-task/task/graphs/contributors
+[semver]: https://semver.org
+[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
+[@andreynering]: https://github.com/andreynering
+[@pd93]: https://github.com/pd93
+[experiments]: https://taskfile.dev/experiments
+[deprecations]: https://taskfile.dev/deprecations
+[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
+[issues]: https://github.com/go-task/task/issues
+[discussions]: https://github.com/go-task/task/discussions
+[discord]: https://discord.gg/6TY36E39UK
+[experiments-project]: https://github.com/orgs/go-task/projects/1
+[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
+[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317

docs/i18n/fr-FR/docusaurus-plugin-content-blog/authors.yml

@@ -3,3 +3,8 @@ andreynering:
   title: Mainteneur de Task
   url: https://github.com/andreynering
   image_url: https://github.com/andreynering.png
+pd93:
+  name: Pete Davison
+  title: Maintainer of Task
+  url: https://github.com/pd93
+  image_url: https://github.com/pd93.png

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/changelog.md

@@ -1,10 +1,18 @@
 ---
 slug: /changelog/
-sidebar_position: 9
+sidebar_position: 14
 ---
 
 # Changelog
 
+## v3.29.1 - 2023-08-26
+
+- Update to Go 1.21 (bump minimum version to 1.20) ([#1302](https://github.com/go-task/task/issues/1302) by [@pd93](https://github.com/pd93))
+- Fix a missing a line break on log when using `--watch` mode ([#1285](https://github.com/go-task/task/issues/1285), [#1297](https://github.com/go-task/task/issues/1297) by [@FilipSolich](https://github.com/FilipSolich)).
+- Fix `defer` on JSON Schema ([#1288](https://github.com/go-task/task/issues/1288) by [@calvinmclean](https://github.com/calvinmclean) and [@andreynering](https://github.com/andreynering)).
+- Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in combination with `includes` ([#1046](https://github.com/go-task/task/issues/1046), [#1205](https://github.com/go-task/task/issues/1205), [#1250](https://github.com/go-task/task/issues/1250), [#1293](https://github.com/go-task/task/issues/1293), [#1312](https://github.com/go-task/task/issues/1312), [#1274](https://github.com/go-task/task/issues/1274) by [@andarto](https://github.com/andarto), [#1309](https://github.com/go-task/task/issues/1309) by [@andreynering](https://github.com/andreynering)).
+- Fix bug on `--status` flag. Running this flag should not have side-effects: it should not update the checksum on `.task`, only report its status ([#1305](https://github.com/go-task/task/issues/1305), [#1307](https://github.com/go-task/task/issues/1307) by [@visciang](https://github.com/visciang), [#1313](https://github.com/go-task/task/issues/1313) by [@andreynering](https://github.com/andreynering)).
+
 ## v3.28.0 - 2023-07-24
 
 - Added the ability to [loop over commands and tasks](https://taskfile.dev/usage/#looping-over-values) using `for` ([#82](https://github.com/go-task/task/issues/82), [#1220](https://github.com/go-task/task/issues/1220) by [@pd93](https://github.com/pd93)).

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/community.md

@@ -1,6 +1,6 @@
 ---
 slug: /community/
-sidebar_position: 10
+sidebar_position: 9
 ---
 
 # Communauté

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/deprecations/deprecations.md

@@ -0,0 +1,12 @@
+---
+slug: /deprecations/
+sidebar_position: 7
+---
+
+# Deprecations
+
+As Task evolves, it occasionally outgrows some of its functionality. This can be because they are no longer useful, because another feature has replaced it or because of a change in the way that Task works internally.
+
+When this happens, we mark the functionality as deprecated. This means that it will be removed in a future version of Task. This functionality will continue to work until that time, but we strongly recommend that you do not implement this functionality in new Taskfiles and make a plan to migrate away from it as soon as possible.
+
+You can view a full list of active deprecations in the "Deprecations" section of the sidebar.

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/deprecations/template.md

@@ -0,0 +1,17 @@
+---
+#This is a template for an experiments documentation
+#Copy this page and fill in the details as necessary
+title: '--- Template ---'
+sidebar_position: -1 #Always push to the top
+draft: true #Hide in production
+---
+
+# {Name of Deprecated Feature}
+
+- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
+- Breaks:
+  - {list any existing functionality that will be broken by this experiment}
+
+{Short description of the feature/behavior and why it is being deprecated}
+
+{Short explanation of any replacement features/behaviors and how users should migrate to it}

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/deprecations/version_2_schema.md

@@ -0,0 +1,22 @@
+---
+slug: /deprecations/version-2-schema/
+---
+
+# Version 2 Schema
+
+- Issue: [#1197][deprecate-version-2-schema]
+- Breaks:
+  - Any Taskfiles that use the version 2 schema
+  - `Taskvar.yml` files
+
+The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
+
+This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
+
+A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
+[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/donate.md

@@ -1,6 +1,6 @@
 ---
 slug: /donate/
-sidebar_position: 15
+sidebar_position: 16
 ---
 
 # Faire un don

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/experiments/experiments.md

@@ -1,6 +1,6 @@
 ---
 slug: /experiments/
-sidebar_position: 5
+sidebar_position: 6
 ---
 
 # Experiments
@@ -11,7 +11,9 @@ All experimental features are subject to breaking changes and/or removal _at any
 
 :::
 
-In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and the deprecated feature that they are intended to replace.
+In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and their status in the [workflow](#workflow).
+
+You can view a full list of active experiments in the "Experiments" section of the sidebar.
 
 You can enable an experimental feature by:
 
@@ -28,43 +30,49 @@ TASK_X_FEATURE=1
 
 Each section below details an experiment or deprecation and explains what the flags/environment variables to enable the experiment are and how the feature's behavior will change. It will also explain what you need to do to migrate any existing Taskfiles to the new behavior.
 
-<!-- EXPERIMENT TEMPLATE - Include sections as necessary...
+## Workflow
 
-### ![experiment] {Feature} ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
+Experiments are a way for us to test out new features in Task before committing to them in a major release. Because this concept is built around the idea of feedback from our community, we have built a workflow for the process of introducing these changes. This ensures that experiments are given the attention and time that they need and that we are getting the best possible results out of them.
 
-- Environment variable: `TASK_X_{feature}`
-- Deprecates: {list any existing functionality that will be deprecated by this experiment}
-- Breaks: {list any existing functionality that will be broken by this experiment}
+The sections below describe the various stages that an experiment must go through from its proposal all the way to being released in a major version of Task.
 
-{Short description of the feature}
+### 1. Proposal
 
-{Short explanation of how users should migrate to the new behavior}
+All experimental features start with a proposal in the form of a GitHub issue. If the maintainers decide that an issue has enough support and is a breaking change or is complex/controversial enough to require user feedback, then the issue will be marked with the ![proposal][] label. At this point, the issue becomes a proposal and a period of consultation begins. During this period, we request that users provide feedback on the proposal and how it might effect their use of Task. It is up to the discretion of the maintainers to decide how long this period lasts.
 
--->
+### 2. Draft
 
-### ![deprecated][] Version 2 Schema ([#1197][deprecate-version-2-schema])
+Once a proposal's consultation ends, a contributor may pick up the work and begin the initial implementation. Once a PR is opened, the maintainers will ensure that it meets the requirements for an experimental feature (i.e. flags are in the right format etc) and merge the feature. Once this code is released, the status will be updated via the ![draft][] label. This indicates that an implementation is now available for use in a release and the experiment is open for feedback.
 
-The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
+:::note
 
-This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
+During the draft period, major changes to the implementation may be made based on the feedback received from users. There are _no stability guarantees_ and experimental features may be abandoned _at any time_.
 
-A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
+:::
 
-### ![experiment][] Gentle Force ([#1200](https://github.com/go-task/task/issues/1200))
+### 3. Candidate
 
-- Environment variable: `TASK_X_FORCE=1`
-- Breaks: `--force` flag
+Once an acceptable level of consensus has been reached by the community and feedback/changes are less frequent/significant, the status may be updated via the ![candidate][] label. This indicates that a proposal is _likely_ to accepted and will enter a period for final comments and minor changes.
 
-The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
+### 4. Stable
 
-This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
+Once a suitable amount of time has passed with no changes or feedback, an experiment will be given the ![stable][] label. At this point, the functionality will be treated like any other feature in Task and any changes _must_ be backward compatible. This allows users to migrate to the new functionality without having to worry about anything breaking in future releases. This provides the best experience for users migrating to a new major version.
 
-If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
+### 5. Released
+
+When making a new major release of Task, all experiments marked as ![stable][] will move to ![released][] and their behaviors will become the new default in Task. Experiments in an earlier stage (i.e. not stable) cannot be released and so will continue to be experiments in the new version.
+
+### Abandoned / Superseded
+
+If an experiment is unsuccessful at any point then it will be given the ![abandoned][] or ![superseded][] labels depending on which is more suitable. These experiments will be removed from Task.
 
 <!-- prettier-ignore-start -->
 
 <!-- prettier-ignore-end -->
-[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
-[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0
-[deprecated]: https://img.shields.io/badge/deprecated-red
-[experiment]: https://img.shields.io/badge/experiment-yellow
+[proposal]: https://img.shields.io/badge/experiment:%20proposal-purple
+[draft]: https://img.shields.io/badge/experiment:%20draft-purple
+[candidate]: https://img.shields.io/badge/experiment:%20candidate-purple
+[stable]: https://img.shields.io/badge/experiment:%20stable-purple
+[released]: https://img.shields.io/badge/experiment:%20released-purple
+[abandoned]: https://img.shields.io/badge/experiment:%20abandoned-purple
+[superseded]: https://img.shields.io/badge/experiment:%20superseded-purple

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/experiments/gentle_force.md

@@ -0,0 +1,21 @@
+---
+slug: /experiments/gentle-force/
+---
+
+# Gentle Force
+
+- Issue: [#1200][gentle-force-experiment]
+- Environment variable: `TASK_X_FORCE=1`
+- Breaks:
+  - `--force` flag
+
+The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
+
+This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
+
+If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[gentle-force-experiment]: https://github.com/go-task/task/issues/1200

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/experiments/remote_taskfiles.md

@@ -0,0 +1,54 @@
+---
+slug: /experiments/remote-taskfiles/
+---
+
+# Remote Taskfiles
+
+- Issue: [#1317][remote-taskfiles-experiment]
+- Environment variable: `TASK_X_REMOTE_TASKFILES=1`
+
+This experiment allows you to specify a remote Taskfile URL when including a Taskfile. For example:
+
+```yaml
+version: '3'
+
+include:
+  my-remote-namespace: https://raw.githubusercontent.com/my-org/my-repo/main/Taskfile.yml
+```
+
+This works exactly the same way that including a local file does. Any tasks in the remote Taskfile will be available to run from your main Taskfile via the namespace `my-remote-namespace`. For example, if the remote file contains the following:
+
+```yaml
+version: '3'
+
+tasks:
+  hello:
+    silent: true
+    cmds:
+      - echo "Hello from the remote Taskfile!"
+```
+
+and you run `task my-remote-namespace:hello`, it will print the text: "Hello from the remote Taskfile!" to your console.
+
+## Security
+
+Running commands from sources that you do not control is always a potential security risk. For this reason, we have added some checks when using remote Taskfiles:
+
+1. When running a task from a remote Taskfile for the first time, Task will print a warning to the console asking you to check that you are sure that you trust the source of the Taskfile. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the remote Taskfile will run and further calls to the remote Taskfile will not prompt you again.
+2. Whenever you run a remote Taskfile, Task will create and store a checksum of the file that you are running. If the checksum changes, then Task will print another warning to the console to inform you that the contents of the remote file has changed. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the checksum will be updated and the remote Taskfile will run.
+
+Task currently supports both `http` and `https` URLs. However, the `http` requests will not execute by default unless you run the task with the `--insecure` flag. This is to protect you from accidentally running a remote Taskfile that is hosted on and unencrypted connection. Sources that are not protected by TLS are vulnerable to [man-in-the-middle attacks][man-in-the-middle-attacks] and should be avoided unless you know what you are doing.
+
+## Caching & Running Offline
+
+If for whatever reason, you don't have access to the internet, but you still need to be able to run your tasks, you are able to use the `--download` flag to store a cached copy of the remote Taskfile.
+
+<!-- TODO: The following behavior may change -->
+
+If Task detects that you have a local copy of the remote Taskfile, it will use your local copy instead of downloading the remote file. You can force Task to work offline by using the `--offline` flag. This will prevent Task from making any calls to remote sources.
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
+[man-in-the-middle-attacks]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/experiments/template.md

@@ -0,0 +1,20 @@
+---
+#This is a template for an experiments documentation
+#Copy this page and fill in the details as necessary
+title: '--- Template ---'
+sidebar_position: -1 #Always push to the top
+draft: true #Hide in production
+---
+
+# {Name of Experiment}
+
+- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
+- Environment variable: `TASK_X_{feature}`
+- Breaks:
+  - {list any existing functionality that will be broken by this experiment}
+- Deprecations:
+  - {link to any deprecation pages related to this experiment}
+
+{Short description of the feature}
+
+{Short explanation of how users should migrate to the new behavior}

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/faq.md

@@ -1,6 +1,6 @@
 ---
 slug: /faq/
-sidebar_position: 7
+sidebar_position: 15
 ---
 
 # FAQ

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/integrations.md

@@ -1,6 +1,6 @@
 ---
 slug: /integrations/
-sidebar_position: 6
+sidebar_position: 8
 ---
 
 # Integrations

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/releasing.md

@@ -26,6 +26,10 @@ The [snap package][snappackage] requires to manual steps to release a new versio
 - Updating the current version on [snapcraft.yaml][snapcraftyaml].
 - Moving both `amd64`, `armhf` and `arm64` new artifacts to the stable channel on the [Snapcraft dashboard][snapcraftdashboard].
 
+# winget
+
+winget also requires manual steps to be completed. By running `task test-release` locally, manifest files will be generated on `dist/winget/manifests/t/Task/Task/v{version}`. [Upload the manifest directory into this fork](https://github.com/go-task/winget-pkgs/tree/master/manifests/t/Task/Task) and open a pull request into [this repository](https://github.com/microsoft/winget-pkgs).
+
 # Scoop
 
 Scoop is a command-line package manager for the Windows operating system. Scoop package manifests are maintained by the community. Scoop owners usually take care of updating versions there by editing [this file](https://github.com/ScoopInstaller/Main/blob/master/bucket/task.json). If you think its Task version is outdated, open an issue to let us know.

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/styleguide.md

@@ -1,6 +1,6 @@
 ---
 slug: /styleguide/
-sidebar_position: 8
+sidebar_position: 10
 ---
 
 # Guide de style

docs/i18n/fr-FR/docusaurus-plugin-content-docs/current/taskfile_versions.md

@@ -1,6 +1,6 @@
 ---
 slug: /taskfile-versions/
-sidebar_position: 14
+sidebar_position: 5
 ---
 
 # Taskfile Versions
@@ -21,7 +21,7 @@ These are some major changes done on `v3`:
 - Added support for `.env` like files
 - Added `label:` setting to task so one can override how the task name appear in the logs
 - A global `method:` was added to allow setting the default method, and Task's default changed to `checksum`
-- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the md5 checksum and greatest modification timestamp of the files listed on `sources:`
+- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the XXH3 checksum and greatest modification timestamp of the files listed on `sources:`
 - Also, the `TASK` variable is always available with the current task name
 - CLI variables are always treated as global variables
 - Added `dir:` option to `includes` to allow choosing on which directory an included Taskfile will run:

docs/i18n/ja-JP/docusaurus-plugin-content-blog/2023-09-02-introducing-experiments.md

@@ -0,0 +1,93 @@
+---
+title: Introducing Experiments
+description: A look at where task is, where it's going and how we're going to get there.
+slug: task-in-2023
+authors:
+  - pd93
+tags:
+  - experiments
+  - breaking-changes
+  - roadmap
+  - v4
+image: https://i.imgur.com/mErPwqL.png
+hide_table_of_contents: false
+---
+
+Lately, Task has been growing extremely quickly and I've found myself thinking a lot about the future of the project and how we continue to evolve and grow. I'm not much of a writer, but I think one of the things we could do better is to communicate these kinds of thoughts to the community. So, with that in mind, this is the first (hopefully of many) blog posts talking about Task and what we're up to.
+
+<!--truncate-->
+
+## :calendar: So, what have we been up to?
+
+Over the past 12 months or so, [@andreynering][] (Author and maintainer of the project) and I ([@pd93][]) have been working in our spare time to maintain and improve v3 of Task and we've made some amazing progress. Here are just some of the things we've released in that time:
+
+- An official [extension for VS Code][vscode-task].
+- Internal Tasks ([#818](https://github.com/go-task/task/pull/818)).
+- Task aliases ([#879](https://github.com/go-task/task/pull/879)).
+- Looping over tasks ([#1220](https://github.com/go-task/task/pull/1200)).
+- A series of refactors to the core codebase to make it more maintainable and extensible.
+- Loads of bug fixes and improvements.
+- An integration with [Crowdin][crowdin]. Work is in progress on making our docs available in **7 new languages** (Special thanks to all our translators for the huge help with this!).
+- And much, much more! :sparkles:
+
+We're also working on adding some really exciting and highly requested features to Task such as having the ability to run remote Taskfiles ([#1317](https://github.com/go-task/task/issues/1317)).
+
+None of this would have been possible without the [150 or so (and growing) contributors][contributors] to the project, numerous sponsors and a passionate community of users. Together we have more than doubled the number of GitHub stars to over 8400 :star: since the beginning of 2022 and this continues to accelerate. We can't thank you all enough for your help and support! :rocket:
+
+[![Star History Chart](https://api.star-history.com/svg?repos=go-task/task&type=Date)](https://star-history.com/#go-task/task&Date)
+
+## What's next? :thinking_face:
+
+It's extremely motivating to see so many people using and loving Task. However, in this time we've also seen an increase in the number of issues and feature requests. In particular, issues that require some kind of breaking change to Task. This isn't a bad thing, but as we grow we need to be more responsible about how we address these changes in a way that ensures stability and compatibility for existing users and their Taskfiles.
+
+At this point you're probably thinking something like:
+
+> "But you use [semantic versioning][semver] - Just release a new major version with your breaking changes."
+
+And you'd be right... sort of. In theory, this sounds great, but the reality is that we don't have the time to commit to a major overhaul of Task in one big bang release. This would require a colossal amount of time and coordination and with full time jobs and personal lives to tend to, this is a difficult commitment to make. Smaller, more frequent major releases are also a significant inconvenience for users as they have to constantly keep up-to-date with our breaking changes. Fortunately, there is a better way.
+
+## What's going to change? :face_with_monocle:
+
+Going forwards, breaking changes will be allowed into _minor_ versions of Task as "experimental features". To access these features users will need opt-in by enabling feature flags. This will allow us to release new features slowly and gather feedback from the community before making them the default behavior in a future major release.
+
+To prepare users for the next major release, we will maintain a list of [deprecated features][deprecations] and [experiments][experiments] on our docs website and publish information on how to migrate to the new behavior.
+
+You can read the [full breaking change proposal][breaking-change-proposal] and view all the [current experiments and their status][experiments-project] on GitHub including the [Gentle Force][gentle-force-experiment] and [Remote Taskfiles][remote-taskfiles-experiment] experiments.
+
+## What will happen to v2/v3 features?
+
+v2 has been [officially deprecated][deprecate-version-2-schema]. If you're still using a Taskfile with `version: "2"` at the top we _strongly recommend_ that you upgrade as soon as possible. Removing v2 will allow us to tidy up the codebase and focus on new functionality instead.
+
+When v4 is released, we will continue to support v3 for a period of time (bug fixes etc). However, since we are moving from a backward-compatibility model to a forwards-compatibility model, **v4 itself will not be backwards compatible with v3**.
+
+## v4 When? :eyes:
+
+:shrug: When it's ready.
+
+In all seriousness, we don't have a timeline for this yet. We'll be working on the most serious deficiencies of the v3 API first and regularly evaluating the state of the project. When we feel its in a good, stable place and we have a clear upgrade path for users and a number of stable experiments, we'll start to think about v4.
+
+## :wave: Final thoughts
+
+Task is growing fast and we're excited to see where it goes next. We hope that the steps we're taking to improve the project and our process will help us to continue to grow. As always, if you have any questions or feedback, we encourage you to comment on or open [issues][issues] and [discussions][discussions] on GitHub. Alternatively, you can join us on [Discord][discord].
+
+I plan to write more of these blog posts in the future on a variety of Task-related topics, so make sure to check in occasionally and see what we're up to!
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[vscode-task]: https://github.com/go-task/vscode-task
+[crowdin]: https://crowdin.com
+[contributors]: https://github.com/go-task/task/graphs/contributors
+[semver]: https://semver.org
+[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
+[@andreynering]: https://github.com/andreynering
+[@pd93]: https://github.com/pd93
+[experiments]: https://taskfile.dev/experiments
+[deprecations]: https://taskfile.dev/deprecations
+[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
+[issues]: https://github.com/go-task/task/issues
+[discussions]: https://github.com/go-task/task/discussions
+[discord]: https://discord.gg/6TY36E39UK
+[experiments-project]: https://github.com/orgs/go-task/projects/1
+[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
+[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317

docs/i18n/ja-JP/docusaurus-plugin-content-blog/authors.yml

@@ -3,3 +3,8 @@ andreynering:
   title: Taskメンテナー
   url: https://github.com/andreynering
   image_url: https://github.com/andreynering.png
+pd93:
+  name: Pete Davison
+  title: Maintainer of Task
+  url: https://github.com/pd93
+  image_url: https://github.com/pd93.png

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/changelog.md

@@ -1,10 +1,18 @@
 ---
 slug: /changelog/
-sidebar_position: 9
+sidebar_position: 14
 ---
 
 # Changelog
 
+## v3.29.1 - 2023-08-26
+
+- Update to Go 1.21 (bump minimum version to 1.20) ([#1302](https://github.com/go-task/task/issues/1302) by [@pd93](https://github.com/pd93))
+- Fix a missing a line break on log when using `--watch` mode ([#1285](https://github.com/go-task/task/issues/1285), [#1297](https://github.com/go-task/task/issues/1297) by [@FilipSolich](https://github.com/FilipSolich)).
+- Fix `defer` on JSON Schema ([#1288](https://github.com/go-task/task/issues/1288) by [@calvinmclean](https://github.com/calvinmclean) and [@andreynering](https://github.com/andreynering)).
+- Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in combination with `includes` ([#1046](https://github.com/go-task/task/issues/1046), [#1205](https://github.com/go-task/task/issues/1205), [#1250](https://github.com/go-task/task/issues/1250), [#1293](https://github.com/go-task/task/issues/1293), [#1312](https://github.com/go-task/task/issues/1312), [#1274](https://github.com/go-task/task/issues/1274) by [@andarto](https://github.com/andarto), [#1309](https://github.com/go-task/task/issues/1309) by [@andreynering](https://github.com/andreynering)).
+- Fix bug on `--status` flag. Running this flag should not have side-effects: it should not update the checksum on `.task`, only report its status ([#1305](https://github.com/go-task/task/issues/1305), [#1307](https://github.com/go-task/task/issues/1307) by [@visciang](https://github.com/visciang), [#1313](https://github.com/go-task/task/issues/1313) by [@andreynering](https://github.com/andreynering)).
+
 ## v3.28.0 - 2023-07-24
 
 - Added the ability to [loop over commands and tasks](https://taskfile.dev/usage/#looping-over-values) using `for` ([#82](https://github.com/go-task/task/issues/82), [#1220](https://github.com/go-task/task/issues/1220) by [@pd93](https://github.com/pd93)).

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/community.md

@@ -1,6 +1,6 @@
 ---
 slug: /community/
-sidebar_position: 10
+sidebar_position: 9
 ---
 
 # Community

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/deprecations/deprecations.md

@@ -0,0 +1,12 @@
+---
+slug: /deprecations/
+sidebar_position: 7
+---
+
+# Deprecations
+
+As Task evolves, it occasionally outgrows some of its functionality. This can be because they are no longer useful, because another feature has replaced it or because of a change in the way that Task works internally.
+
+When this happens, we mark the functionality as deprecated. This means that it will be removed in a future version of Task. This functionality will continue to work until that time, but we strongly recommend that you do not implement this functionality in new Taskfiles and make a plan to migrate away from it as soon as possible.
+
+You can view a full list of active deprecations in the "Deprecations" section of the sidebar.

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/deprecations/template.md

@@ -0,0 +1,17 @@
+---
+#This is a template for an experiments documentation
+#Copy this page and fill in the details as necessary
+title: '--- Template ---'
+sidebar_position: -1 #Always push to the top
+draft: true #Hide in production
+---
+
+# {Name of Deprecated Feature}
+
+- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
+- Breaks:
+  - {list any existing functionality that will be broken by this experiment}
+
+{Short description of the feature/behavior and why it is being deprecated}
+
+{Short explanation of any replacement features/behaviors and how users should migrate to it}

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/deprecations/version_2_schema.md

@@ -0,0 +1,22 @@
+---
+slug: /deprecations/version-2-schema/
+---
+
+# Version 2 Schema
+
+- Issue: [#1197][deprecate-version-2-schema]
+- Breaks:
+  - Any Taskfiles that use the version 2 schema
+  - `Taskvar.yml` files
+
+The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
+
+This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
+
+A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
+[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/donate.md

@@ -1,6 +1,6 @@
 ---
 slug: /donate/
-sidebar_position: 15
+sidebar_position: 16
 ---
 
 # 寄付

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/experiments/experiments.md

@@ -1,6 +1,6 @@
 ---
 slug: /experiments/
-sidebar_position: 5
+sidebar_position: 6
 ---
 
 # Experiments
@@ -11,7 +11,9 @@ All experimental features are subject to breaking changes and/or removal _at any
 
 :::
 
-In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and the deprecated feature that they are intended to replace.
+In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and their status in the [workflow](#workflow).
+
+You can view a full list of active experiments in the "Experiments" section of the sidebar.
 
 You can enable an experimental feature by:
 
@@ -28,43 +30,49 @@ TASK_X_FEATURE=1
 
 Each section below details an experiment or deprecation and explains what the flags/environment variables to enable the experiment are and how the feature's behavior will change. It will also explain what you need to do to migrate any existing Taskfiles to the new behavior.
 
-<!-- EXPERIMENT TEMPLATE - Include sections as necessary...
+## Workflow
 
-### ![experiment] {Feature} ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
+Experiments are a way for us to test out new features in Task before committing to them in a major release. Because this concept is built around the idea of feedback from our community, we have built a workflow for the process of introducing these changes. This ensures that experiments are given the attention and time that they need and that we are getting the best possible results out of them.
 
-- Environment variable: `TASK_X_{feature}`
-- Deprecates: {list any existing functionality that will be deprecated by this experiment}
-- Breaks: {list any existing functionality that will be broken by this experiment}
+The sections below describe the various stages that an experiment must go through from its proposal all the way to being released in a major version of Task.
 
-{Short description of the feature}
+### 1. Proposal
 
-{Short explanation of how users should migrate to the new behavior}
+All experimental features start with a proposal in the form of a GitHub issue. If the maintainers decide that an issue has enough support and is a breaking change or is complex/controversial enough to require user feedback, then the issue will be marked with the ![proposal][] label. At this point, the issue becomes a proposal and a period of consultation begins. During this period, we request that users provide feedback on the proposal and how it might effect their use of Task. It is up to the discretion of the maintainers to decide how long this period lasts.
 
--->
+### 2. Draft
 
-### ![deprecated][] Version 2 Schema ([#1197][deprecate-version-2-schema])
+Once a proposal's consultation ends, a contributor may pick up the work and begin the initial implementation. Once a PR is opened, the maintainers will ensure that it meets the requirements for an experimental feature (i.e. flags are in the right format etc) and merge the feature. Once this code is released, the status will be updated via the ![draft][] label. This indicates that an implementation is now available for use in a release and the experiment is open for feedback.
 
-The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
+:::note
 
-This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
+During the draft period, major changes to the implementation may be made based on the feedback received from users. There are _no stability guarantees_ and experimental features may be abandoned _at any time_.
 
-A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
+:::
 
-### ![experiment][] Gentle Force ([#1200](https://github.com/go-task/task/issues/1200))
+### 3. Candidate
 
-- Environment variable: `TASK_X_FORCE=1`
-- Breaks: `--force` flag
+Once an acceptable level of consensus has been reached by the community and feedback/changes are less frequent/significant, the status may be updated via the ![candidate][] label. This indicates that a proposal is _likely_ to accepted and will enter a period for final comments and minor changes.
 
-The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
+### 4. Stable
 
-This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
+Once a suitable amount of time has passed with no changes or feedback, an experiment will be given the ![stable][] label. At this point, the functionality will be treated like any other feature in Task and any changes _must_ be backward compatible. This allows users to migrate to the new functionality without having to worry about anything breaking in future releases. This provides the best experience for users migrating to a new major version.
 
-If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
+### 5. Released
+
+When making a new major release of Task, all experiments marked as ![stable][] will move to ![released][] and their behaviors will become the new default in Task. Experiments in an earlier stage (i.e. not stable) cannot be released and so will continue to be experiments in the new version.
+
+### Abandoned / Superseded
+
+If an experiment is unsuccessful at any point then it will be given the ![abandoned][] or ![superseded][] labels depending on which is more suitable. These experiments will be removed from Task.
 
 <!-- prettier-ignore-start -->
 
 <!-- prettier-ignore-end -->
-[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
-[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0
-[deprecated]: https://img.shields.io/badge/deprecated-red
-[experiment]: https://img.shields.io/badge/experiment-yellow
+[proposal]: https://img.shields.io/badge/experiment:%20proposal-purple
+[draft]: https://img.shields.io/badge/experiment:%20draft-purple
+[candidate]: https://img.shields.io/badge/experiment:%20candidate-purple
+[stable]: https://img.shields.io/badge/experiment:%20stable-purple
+[released]: https://img.shields.io/badge/experiment:%20released-purple
+[abandoned]: https://img.shields.io/badge/experiment:%20abandoned-purple
+[superseded]: https://img.shields.io/badge/experiment:%20superseded-purple

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/experiments/gentle_force.md

@@ -0,0 +1,21 @@
+---
+slug: /experiments/gentle-force/
+---
+
+# Gentle Force
+
+- Issue: [#1200][gentle-force-experiment]
+- Environment variable: `TASK_X_FORCE=1`
+- Breaks:
+  - `--force` flag
+
+The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
+
+This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
+
+If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[gentle-force-experiment]: https://github.com/go-task/task/issues/1200

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/experiments/remote_taskfiles.md

@@ -0,0 +1,54 @@
+---
+slug: /experiments/remote-taskfiles/
+---
+
+# Remote Taskfiles
+
+- Issue: [#1317][remote-taskfiles-experiment]
+- Environment variable: `TASK_X_REMOTE_TASKFILES=1`
+
+This experiment allows you to specify a remote Taskfile URL when including a Taskfile. For example:
+
+```yaml
+version: '3'
+
+include:
+  my-remote-namespace: https://raw.githubusercontent.com/my-org/my-repo/main/Taskfile.yml
+```
+
+This works exactly the same way that including a local file does. Any tasks in the remote Taskfile will be available to run from your main Taskfile via the namespace `my-remote-namespace`. For example, if the remote file contains the following:
+
+```yaml
+version: '3'
+
+tasks:
+  hello:
+    silent: true
+    cmds:
+      - echo "Hello from the remote Taskfile!"
+```
+
+and you run `task my-remote-namespace:hello`, it will print the text: "Hello from the remote Taskfile!" to your console.
+
+## Security
+
+Running commands from sources that you do not control is always a potential security risk. For this reason, we have added some checks when using remote Taskfiles:
+
+1. When running a task from a remote Taskfile for the first time, Task will print a warning to the console asking you to check that you are sure that you trust the source of the Taskfile. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the remote Taskfile will run and further calls to the remote Taskfile will not prompt you again.
+2. Whenever you run a remote Taskfile, Task will create and store a checksum of the file that you are running. If the checksum changes, then Task will print another warning to the console to inform you that the contents of the remote file has changed. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the checksum will be updated and the remote Taskfile will run.
+
+Task currently supports both `http` and `https` URLs. However, the `http` requests will not execute by default unless you run the task with the `--insecure` flag. This is to protect you from accidentally running a remote Taskfile that is hosted on and unencrypted connection. Sources that are not protected by TLS are vulnerable to [man-in-the-middle attacks][man-in-the-middle-attacks] and should be avoided unless you know what you are doing.
+
+## Caching & Running Offline
+
+If for whatever reason, you don't have access to the internet, but you still need to be able to run your tasks, you are able to use the `--download` flag to store a cached copy of the remote Taskfile.
+
+<!-- TODO: The following behavior may change -->
+
+If Task detects that you have a local copy of the remote Taskfile, it will use your local copy instead of downloading the remote file. You can force Task to work offline by using the `--offline` flag. This will prevent Task from making any calls to remote sources.
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
+[man-in-the-middle-attacks]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/experiments/template.md

@@ -0,0 +1,20 @@
+---
+#This is a template for an experiments documentation
+#Copy this page and fill in the details as necessary
+title: '--- Template ---'
+sidebar_position: -1 #Always push to the top
+draft: true #Hide in production
+---
+
+# {Name of Experiment}
+
+- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
+- Environment variable: `TASK_X_{feature}`
+- Breaks:
+  - {list any existing functionality that will be broken by this experiment}
+- Deprecations:
+  - {link to any deprecation pages related to this experiment}
+
+{Short description of the feature}
+
+{Short explanation of how users should migrate to the new behavior}

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/faq.md

@@ -1,6 +1,6 @@
 ---
 slug: /faq/
-sidebar_position: 7
+sidebar_position: 15
 ---
 
 # FAQ

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/integrations.md

@@ -1,6 +1,6 @@
 ---
 slug: /integrations/
-sidebar_position: 6
+sidebar_position: 8
 ---
 
 # Integrations

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/releasing.md

@@ -26,6 +26,10 @@ npmにリリースするには、[`package.json`][packagejson]でバージョン
 - [snapcraft.yaml][snapcraftyaml]で現在のバージョンを更新する。
 - [Snapcraftダッシュボード][snapcraftdashboard]で、`amd64`、`armhf`、`arm64`の新しい成果物を全てstableチャンネルに移動させる。
 
+# winget
+
+wingetもマニュアルのステップが必要です。 `task test-release`をローカルで実行すると、マニフェストファイルが`dist/winget/manifests/t/Task/Task/v{version}`に生成されます。 [マニフェストディレクトリをこのフォーク](https://github.com/go-task/winget-pkgs/tree/master/manifests/t/Task/Task)にアップロードし、[このリポジトリ](https://github.com/microsoft/winget-pkgs)にプルリクエストを作ってください。
+
 # Scoop
 
 ScoopはWindowsオペレーティングシステム用のコマンドラインパッケージマネージャーです。 Scoopパッケージマニフェストはコミュニティによって管理されています。 Scoopの所有者は通常、[このファイル](https://github.com/ScoopInstaller/Main/blob/master/bucket/task.json)を編集することでバージョンを更新します。 Taskのバージョンが古くなっていると思われる場合は、Issueを作成してお知らせください。

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/styleguide.md

@@ -1,6 +1,6 @@
 ---
 slug: /styleguide/
-sidebar_position: 8
+sidebar_position: 10
 ---
 
 # スタイルガイド

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/taskfile_versions.md

@@ -1,6 +1,6 @@
 ---
 slug: /taskfile-versions/
-sidebar_position: 14
+sidebar_position: 5
 ---
 
 # Taskfile Versions
@@ -21,7 +21,7 @@ These are some major changes done on `v3`:
 - Added support for `.env` like files
 - Added `label:` setting to task so one can override how the task name appear in the logs
 - A global `method:` was added to allow setting the default method, and Task's default changed to `checksum`
-- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the md5 checksum and greatest modification timestamp of the files listed on `sources:`
+- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the XXH3 checksum and greatest modification timestamp of the files listed on `sources:`
 - Also, the `TASK` variable is always available with the current task name
 - CLI variables are always treated as global variables
 - Added `dir:` option to `includes` to allow choosing on which directory an included Taskfile will run:

docs/i18n/ja-JP/docusaurus-plugin-content-docs/current/usage.md

@@ -293,7 +293,7 @@ includes:
       DOCKER_IMAGE: frontend_image
 ```
 
-### Namespace aliases
+### ネームスペースのエイリアス
 
 When including a Taskfile, you can give the namespace a list of `aliases`. This works in the same way as [task aliases](#task-aliases) and can be used together to create shorter and easier-to-type commands.
 
@@ -312,7 +312,7 @@ Vars declared in the included Taskfile have preference over the variables in the
 
 :::
 
-## Internal tasks
+## インターナルタスク
 
 Internal tasks are tasks that cannot be called directly by the user. They will not appear in the output when running `task --list|--list-all`. Other tasks may call internal tasks in the usual way. This is useful for creating reusable, function-like tasks that have no useful purpose on the command line.
 
@@ -332,7 +332,7 @@ tasks:
       - docker build -t {{.DOCKER_IMAGE}} .
 ```
 
-## Task directory
+## タスクディレクトリ
 
 By default, tasks will be executed in the directory where the Taskfile is located. But you can easily make the task run in another folder, informing `dir`:
 
@@ -349,7 +349,7 @@ tasks:
 
 If the directory does not exist, `task` creates it.
 
-## Task dependencies
+## タスクの依存関係
 
 > Dependencies run in parallel, so dependencies of a task should not depend one another. If you want to force tasks to run serially, take a look at the [Calling Another Task](#calling-another-task) section below.
 

docs/i18n/pt-BR/docusaurus-plugin-content-blog/2023-09-02-introducing-experiments.md

@@ -0,0 +1,93 @@
+---
+title: Introducing Experiments
+description: A look at where task is, where it's going and how we're going to get there.
+slug: task-in-2023
+authors:
+  - pd93
+tags:
+  - experiments
+  - breaking-changes
+  - roadmap
+  - v4
+image: https://i.imgur.com/mErPwqL.png
+hide_table_of_contents: false
+---
+
+Lately, Task has been growing extremely quickly and I've found myself thinking a lot about the future of the project and how we continue to evolve and grow. I'm not much of a writer, but I think one of the things we could do better is to communicate these kinds of thoughts to the community. So, with that in mind, this is the first (hopefully of many) blog posts talking about Task and what we're up to.
+
+<!--truncate-->
+
+## :calendar: So, what have we been up to?
+
+Over the past 12 months or so, [@andreynering][] (Author and maintainer of the project) and I ([@pd93][]) have been working in our spare time to maintain and improve v3 of Task and we've made some amazing progress. Here are just some of the things we've released in that time:
+
+- An official [extension for VS Code][vscode-task].
+- Internal Tasks ([#818](https://github.com/go-task/task/pull/818)).
+- Task aliases ([#879](https://github.com/go-task/task/pull/879)).
+- Looping over tasks ([#1220](https://github.com/go-task/task/pull/1200)).
+- A series of refactors to the core codebase to make it more maintainable and extensible.
+- Loads of bug fixes and improvements.
+- An integration with [Crowdin][crowdin]. Work is in progress on making our docs available in **7 new languages** (Special thanks to all our translators for the huge help with this!).
+- And much, much more! :sparkles:
+
+We're also working on adding some really exciting and highly requested features to Task such as having the ability to run remote Taskfiles ([#1317](https://github.com/go-task/task/issues/1317)).
+
+None of this would have been possible without the [150 or so (and growing) contributors][contributors] to the project, numerous sponsors and a passionate community of users. Together we have more than doubled the number of GitHub stars to over 8400 :star: since the beginning of 2022 and this continues to accelerate. We can't thank you all enough for your help and support! :rocket:
+
+[![Star History Chart](https://api.star-history.com/svg?repos=go-task/task&type=Date)](https://star-history.com/#go-task/task&Date)
+
+## What's next? :thinking_face:
+
+It's extremely motivating to see so many people using and loving Task. However, in this time we've also seen an increase in the number of issues and feature requests. In particular, issues that require some kind of breaking change to Task. This isn't a bad thing, but as we grow we need to be more responsible about how we address these changes in a way that ensures stability and compatibility for existing users and their Taskfiles.
+
+At this point you're probably thinking something like:
+
+> "But you use [semantic versioning][semver] - Just release a new major version with your breaking changes."
+
+And you'd be right... sort of. In theory, this sounds great, but the reality is that we don't have the time to commit to a major overhaul of Task in one big bang release. This would require a colossal amount of time and coordination and with full time jobs and personal lives to tend to, this is a difficult commitment to make. Smaller, more frequent major releases are also a significant inconvenience for users as they have to constantly keep up-to-date with our breaking changes. Fortunately, there is a better way.
+
+## What's going to change? :face_with_monocle:
+
+Going forwards, breaking changes will be allowed into _minor_ versions of Task as "experimental features". To access these features users will need opt-in by enabling feature flags. This will allow us to release new features slowly and gather feedback from the community before making them the default behavior in a future major release.
+
+To prepare users for the next major release, we will maintain a list of [deprecated features][deprecations] and [experiments][experiments] on our docs website and publish information on how to migrate to the new behavior.
+
+You can read the [full breaking change proposal][breaking-change-proposal] and view all the [current experiments and their status][experiments-project] on GitHub including the [Gentle Force][gentle-force-experiment] and [Remote Taskfiles][remote-taskfiles-experiment] experiments.
+
+## What will happen to v2/v3 features?
+
+v2 has been [officially deprecated][deprecate-version-2-schema]. If you're still using a Taskfile with `version: "2"` at the top we _strongly recommend_ that you upgrade as soon as possible. Removing v2 will allow us to tidy up the codebase and focus on new functionality instead.
+
+When v4 is released, we will continue to support v3 for a period of time (bug fixes etc). However, since we are moving from a backward-compatibility model to a forwards-compatibility model, **v4 itself will not be backwards compatible with v3**.
+
+## v4 When? :eyes:
+
+:shrug: When it's ready.
+
+In all seriousness, we don't have a timeline for this yet. We'll be working on the most serious deficiencies of the v3 API first and regularly evaluating the state of the project. When we feel its in a good, stable place and we have a clear upgrade path for users and a number of stable experiments, we'll start to think about v4.
+
+## :wave: Final thoughts
+
+Task is growing fast and we're excited to see where it goes next. We hope that the steps we're taking to improve the project and our process will help us to continue to grow. As always, if you have any questions or feedback, we encourage you to comment on or open [issues][issues] and [discussions][discussions] on GitHub. Alternatively, you can join us on [Discord][discord].
+
+I plan to write more of these blog posts in the future on a variety of Task-related topics, so make sure to check in occasionally and see what we're up to!
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[vscode-task]: https://github.com/go-task/vscode-task
+[crowdin]: https://crowdin.com
+[contributors]: https://github.com/go-task/task/graphs/contributors
+[semver]: https://semver.org
+[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
+[@andreynering]: https://github.com/andreynering
+[@pd93]: https://github.com/pd93
+[experiments]: https://taskfile.dev/experiments
+[deprecations]: https://taskfile.dev/deprecations
+[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
+[issues]: https://github.com/go-task/task/issues
+[discussions]: https://github.com/go-task/task/discussions
+[discord]: https://discord.gg/6TY36E39UK
+[experiments-project]: https://github.com/orgs/go-task/projects/1
+[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
+[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317

docs/i18n/pt-BR/docusaurus-plugin-content-blog/authors.yml

@@ -3,3 +3,8 @@ andreynering:
   title: Mantenedor do Task
   url: https://github.com/andreynering
   image_url: https://github.com/andreynering.png
+pd93:
+  name: Pete Davison
+  title: Maintainer of Task
+  url: https://github.com/pd93
+  image_url: https://github.com/pd93.png

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/changelog.md

@@ -1,10 +1,18 @@
 ---
 slug: /changelog/
-sidebar_position: 9
+sidebar_position: 14
 ---
 
 # Changelog
 
+## v3.29.1 - 2023-08-26
+
+- Update to Go 1.21 (bump minimum version to 1.20) ([#1302](https://github.com/go-task/task/issues/1302) by [@pd93](https://github.com/pd93))
+- Fix a missing a line break on log when using `--watch` mode ([#1285](https://github.com/go-task/task/issues/1285), [#1297](https://github.com/go-task/task/issues/1297) by [@FilipSolich](https://github.com/FilipSolich)).
+- Fix `defer` on JSON Schema ([#1288](https://github.com/go-task/task/issues/1288) by [@calvinmclean](https://github.com/calvinmclean) and [@andreynering](https://github.com/andreynering)).
+- Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in combination with `includes` ([#1046](https://github.com/go-task/task/issues/1046), [#1205](https://github.com/go-task/task/issues/1205), [#1250](https://github.com/go-task/task/issues/1250), [#1293](https://github.com/go-task/task/issues/1293), [#1312](https://github.com/go-task/task/issues/1312), [#1274](https://github.com/go-task/task/issues/1274) by [@andarto](https://github.com/andarto), [#1309](https://github.com/go-task/task/issues/1309) by [@andreynering](https://github.com/andreynering)).
+- Fix bug on `--status` flag. Running this flag should not have side-effects: it should not update the checksum on `.task`, only report its status ([#1305](https://github.com/go-task/task/issues/1305), [#1307](https://github.com/go-task/task/issues/1307) by [@visciang](https://github.com/visciang), [#1313](https://github.com/go-task/task/issues/1313) by [@andreynering](https://github.com/andreynering)).
+
 ## v3.28.0 - 2023-07-24
 
 - Added the ability to [loop over commands and tasks](https://taskfile.dev/usage/#looping-over-values) using `for` ([#82](https://github.com/go-task/task/issues/82), [#1220](https://github.com/go-task/task/issues/1220) by [@pd93](https://github.com/pd93)).

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/community.md

@@ -1,6 +1,6 @@
 ---
 slug: /community/
-sidebar_position: 10
+sidebar_position: 9
 ---
 
 # Comunidade

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/deprecations/deprecations.md

@@ -0,0 +1,12 @@
+---
+slug: /deprecations/
+sidebar_position: 7
+---
+
+# Deprecations
+
+As Task evolves, it occasionally outgrows some of its functionality. This can be because they are no longer useful, because another feature has replaced it or because of a change in the way that Task works internally.
+
+When this happens, we mark the functionality as deprecated. This means that it will be removed in a future version of Task. This functionality will continue to work until that time, but we strongly recommend that you do not implement this functionality in new Taskfiles and make a plan to migrate away from it as soon as possible.
+
+You can view a full list of active deprecations in the "Deprecations" section of the sidebar.

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/deprecations/template.md

@@ -0,0 +1,17 @@
+---
+#This is a template for an experiments documentation
+#Copy this page and fill in the details as necessary
+title: '--- Template ---'
+sidebar_position: -1 #Always push to the top
+draft: true #Hide in production
+---
+
+# {Name of Deprecated Feature}
+
+- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
+- Breaks:
+  - {list any existing functionality that will be broken by this experiment}
+
+{Short description of the feature/behavior and why it is being deprecated}
+
+{Short explanation of any replacement features/behaviors and how users should migrate to it}

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/deprecations/version_2_schema.md

@@ -0,0 +1,22 @@
+---
+slug: /deprecations/version-2-schema/
+---
+
+# Version 2 Schema
+
+- Issue: [#1197][deprecate-version-2-schema]
+- Breaks:
+  - Any Taskfiles that use the version 2 schema
+  - `Taskvar.yml` files
+
+The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
+
+This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
+
+A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
+[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/donate.md

@@ -1,6 +1,6 @@
 ---
 slug: /donate/
-sidebar_position: 15
+sidebar_position: 16
 ---
 
 # Doe

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/experiments/experiments.md

@@ -1,6 +1,6 @@
 ---
 slug: /experiments/
-sidebar_position: 5
+sidebar_position: 6
 ---
 
 # Experiments
@@ -11,7 +11,9 @@ All experimental features are subject to breaking changes and/or removal _at any
 
 :::
 
-In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and the deprecated feature that they are intended to replace.
+In order to allow Task to evolve quickly, we roll out breaking changes to minor versions behind experimental flags. This allows us to gather feedback on breaking changes before committing to a major release. This document describes the current set of experimental features and their status in the [workflow](#workflow).
+
+You can view a full list of active experiments in the "Experiments" section of the sidebar.
 
 You can enable an experimental feature by:
 
@@ -28,43 +30,49 @@ TASK_X_FEATURE=1
 
 Each section below details an experiment or deprecation and explains what the flags/environment variables to enable the experiment are and how the feature's behavior will change. It will also explain what you need to do to migrate any existing Taskfiles to the new behavior.
 
-<!-- EXPERIMENT TEMPLATE - Include sections as necessary...
+## Workflow
 
-### ![experiment] {Feature} ([#{issue}](https://github.com/go-task/task/issues/{issue})), ...)
+Experiments are a way for us to test out new features in Task before committing to them in a major release. Because this concept is built around the idea of feedback from our community, we have built a workflow for the process of introducing these changes. This ensures that experiments are given the attention and time that they need and that we are getting the best possible results out of them.
 
-- Environment variable: `TASK_X_{feature}`
-- Deprecates: {list any existing functionality that will be deprecated by this experiment}
-- Breaks: {list any existing functionality that will be broken by this experiment}
+The sections below describe the various stages that an experiment must go through from its proposal all the way to being released in a major version of Task.
 
-{Short description of the feature}
+### 1. Proposal
 
-{Short explanation of how users should migrate to the new behavior}
+All experimental features start with a proposal in the form of a GitHub issue. If the maintainers decide that an issue has enough support and is a breaking change or is complex/controversial enough to require user feedback, then the issue will be marked with the ![proposal][] label. At this point, the issue becomes a proposal and a period of consultation begins. During this period, we request that users provide feedback on the proposal and how it might effect their use of Task. It is up to the discretion of the maintainers to decide how long this period lasts.
 
--->
+### 2. Draft
 
-### ![deprecated][] Version 2 Schema ([#1197][deprecate-version-2-schema])
+Once a proposal's consultation ends, a contributor may pick up the work and begin the initial implementation. Once a PR is opened, the maintainers will ensure that it meets the requirements for an experimental feature (i.e. flags are in the right format etc) and merge the feature. Once this code is released, the status will be updated via the ![draft][] label. This indicates that an implementation is now available for use in a release and the experiment is open for feedback.
 
-The Taskfile v2 schema was introduced in March 2018 and replaced by version 3 in August the following year. Users have had a long time to update and so we feel that it is time to tidy up the codebase and focus on new functionality instead.
+:::note
 
-This notice does not mean that we are immediately removing support for version 2 schemas. However, support will not be extended to future major releases and we _strongly recommend_ that anybody still using a version 2 schema upgrades to version 3 as soon as possible.
+During the draft period, major changes to the implementation may be made based on the feedback received from users. There are _no stability guarantees_ and experimental features may be abandoned _at any time_.
 
-A list of changes between version 2 and version 3 are available in the [Task v3 Release Notes][version-3-release-notes].
+:::
 
-### ![experiment][] Gentle Force ([#1200](https://github.com/go-task/task/issues/1200))
+### 3. Candidate
 
-- Environment variable: `TASK_X_FORCE=1`
-- Breaks: `--force` flag
+Once an acceptable level of consensus has been reached by the community and feedback/changes are less frequent/significant, the status may be updated via the ![candidate][] label. This indicates that a proposal is _likely_ to accepted and will enter a period for final comments and minor changes.
 
-The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
+### 4. Stable
 
-This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
+Once a suitable amount of time has passed with no changes or feedback, an experiment will be given the ![stable][] label. At this point, the functionality will be treated like any other feature in Task and any changes _must_ be backward compatible. This allows users to migrate to the new functionality without having to worry about anything breaking in future releases. This provides the best experience for users migrating to a new major version.
 
-If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
+### 5. Released
+
+When making a new major release of Task, all experiments marked as ![stable][] will move to ![released][] and their behaviors will become the new default in Task. Experiments in an earlier stage (i.e. not stable) cannot be released and so will continue to be experiments in the new version.
+
+### Abandoned / Superseded
+
+If an experiment is unsuccessful at any point then it will be given the ![abandoned][] or ![superseded][] labels depending on which is more suitable. These experiments will be removed from Task.
 
 <!-- prettier-ignore-start -->
 
 <!-- prettier-ignore-end -->
-[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
-[version-3-release-notes]: https://github.com/go-task/task/releases/tag/v3.0.0
-[deprecated]: https://img.shields.io/badge/deprecated-red
-[experiment]: https://img.shields.io/badge/experiment-yellow
+[proposal]: https://img.shields.io/badge/experiment:%20proposal-purple
+[draft]: https://img.shields.io/badge/experiment:%20draft-purple
+[candidate]: https://img.shields.io/badge/experiment:%20candidate-purple
+[stable]: https://img.shields.io/badge/experiment:%20stable-purple
+[released]: https://img.shields.io/badge/experiment:%20released-purple
+[abandoned]: https://img.shields.io/badge/experiment:%20abandoned-purple
+[superseded]: https://img.shields.io/badge/experiment:%20superseded-purple

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/experiments/gentle_force.md

@@ -0,0 +1,21 @@
+---
+slug: /experiments/gentle-force/
+---
+
+# Gentle Force
+
+- Issue: [#1200][gentle-force-experiment]
+- Environment variable: `TASK_X_FORCE=1`
+- Breaks:
+  - `--force` flag
+
+The `--force` flag currently forces _all_ tasks to run regardless of the status checks. This can be useful, but we have found that most of the time users only expect the direct task they are calling to be forced and _not_ all of its dependant tasks.
+
+This experiment changes the `--force` flag to only force the directly called task. All dependant tasks will have their statuses checked as normal and will only run if Task considers them to be out of date. A new `--force-all` flag will also be added to maintain the current behavior for users that need this functionality.
+
+If you want to migrate, but continue to force all dependant tasks to run, you should replace all uses of the `--force` flag with `--force-all`. Alternatively, if you want to adopt the new behavior, you can continue to use the `--force` flag as you do now!
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[gentle-force-experiment]: https://github.com/go-task/task/issues/1200

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/experiments/remote_taskfiles.md

@@ -0,0 +1,54 @@
+---
+slug: /experiments/remote-taskfiles/
+---
+
+# Remote Taskfiles
+
+- Issue: [#1317][remote-taskfiles-experiment]
+- Environment variable: `TASK_X_REMOTE_TASKFILES=1`
+
+This experiment allows you to specify a remote Taskfile URL when including a Taskfile. For example:
+
+```yaml
+version: '3'
+
+include:
+  my-remote-namespace: https://raw.githubusercontent.com/my-org/my-repo/main/Taskfile.yml
+```
+
+This works exactly the same way that including a local file does. Any tasks in the remote Taskfile will be available to run from your main Taskfile via the namespace `my-remote-namespace`. For example, if the remote file contains the following:
+
+```yaml
+version: '3'
+
+tasks:
+  hello:
+    silent: true
+    cmds:
+      - echo "Hello from the remote Taskfile!"
+```
+
+and you run `task my-remote-namespace:hello`, it will print the text: "Hello from the remote Taskfile!" to your console.
+
+## Security
+
+Running commands from sources that you do not control is always a potential security risk. For this reason, we have added some checks when using remote Taskfiles:
+
+1. When running a task from a remote Taskfile for the first time, Task will print a warning to the console asking you to check that you are sure that you trust the source of the Taskfile. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the remote Taskfile will run and further calls to the remote Taskfile will not prompt you again.
+2. Whenever you run a remote Taskfile, Task will create and store a checksum of the file that you are running. If the checksum changes, then Task will print another warning to the console to inform you that the contents of the remote file has changed. If you do not accept the prompt, then Task will exit with code `104` (not trusted) and nothing will run. If you accept the prompt, the checksum will be updated and the remote Taskfile will run.
+
+Task currently supports both `http` and `https` URLs. However, the `http` requests will not execute by default unless you run the task with the `--insecure` flag. This is to protect you from accidentally running a remote Taskfile that is hosted on and unencrypted connection. Sources that are not protected by TLS are vulnerable to [man-in-the-middle attacks][man-in-the-middle-attacks] and should be avoided unless you know what you are doing.
+
+## Caching & Running Offline
+
+If for whatever reason, you don't have access to the internet, but you still need to be able to run your tasks, you are able to use the `--download` flag to store a cached copy of the remote Taskfile.
+
+<!-- TODO: The following behavior may change -->
+
+If Task detects that you have a local copy of the remote Taskfile, it will use your local copy instead of downloading the remote file. You can force Task to work offline by using the `--offline` flag. This will prevent Task from making any calls to remote sources.
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317
+[man-in-the-middle-attacks]: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/experiments/template.md

@@ -0,0 +1,20 @@
+---
+#This is a template for an experiments documentation
+#Copy this page and fill in the details as necessary
+title: '--- Template ---'
+sidebar_position: -1 #Always push to the top
+draft: true #Hide in production
+---
+
+# {Name of Experiment}
+
+- Issue: [#{issue}](https://github.com/go-task/task/issues/{issue})
+- Environment variable: `TASK_X_{feature}`
+- Breaks:
+  - {list any existing functionality that will be broken by this experiment}
+- Deprecations:
+  - {link to any deprecation pages related to this experiment}
+
+{Short description of the feature}
+
+{Short explanation of how users should migrate to the new behavior}

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/faq.md

@@ -1,6 +1,6 @@
 ---
 slug: /faq/
-sidebar_position: 7
+sidebar_position: 15
 ---
 
 # Perguntas frequentes

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/integrations.md

@@ -1,6 +1,6 @@
 ---
 slug: /integrations/
-sidebar_position: 6
+sidebar_position: 8
 ---
 
 # Integrations

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/releasing.md

@@ -26,6 +26,10 @@ The [snap package][snappackage] requires to manual steps to release a new versio
 - Updating the current version on [snapcraft.yaml][snapcraftyaml].
 - Moving both `amd64`, `armhf` and `arm64` new artifacts to the stable channel on the [Snapcraft dashboard][snapcraftdashboard].
 
+# winget
+
+winget also requires manual steps to be completed. By running `task test-release` locally, manifest files will be generated on `dist/winget/manifests/t/Task/Task/v{version}`. [Upload the manifest directory into this fork](https://github.com/go-task/winget-pkgs/tree/master/manifests/t/Task/Task) and open a pull request into [this repository](https://github.com/microsoft/winget-pkgs).
+
 # Scoop
 
 Scoop is a command-line package manager for the Windows operating system. Scoop package manifests are maintained by the community. Scoop owners usually take care of updating versions there by editing [this file](https://github.com/ScoopInstaller/Main/blob/master/bucket/task.json). If you think its Task version is outdated, open an issue to let us know.

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/styleguide.md

@@ -1,6 +1,6 @@
 ---
 slug: /styleguide/
-sidebar_position: 8
+sidebar_position: 10
 ---
 
 # Guia de estilo

docs/i18n/pt-BR/docusaurus-plugin-content-docs/current/taskfile_versions.md

@@ -1,6 +1,6 @@
 ---
 slug: /taskfile-versions/
-sidebar_position: 14
+sidebar_position: 5
 ---
 
 # Versões do Taskfile
@@ -21,7 +21,7 @@ These are some major changes done on `v3`:
 - Added support for `.env` like files
 - Added `label:` setting to task so one can override how the task name appear in the logs
 - A global `method:` was added to allow setting the default method, and Task's default changed to `checksum`
-- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the md5 checksum and greatest modification timestamp of the files listed on `sources:`
+- Two magic variables were added when using `status:`: `CHECKSUM` and `TIMESTAMP` which contains, respectively, the XXH3 checksum and greatest modification timestamp of the files listed on `sources:`
 - Also, the `TASK` variable is always available with the current task name
 - CLI variables are always treated as global variables
 - Added `dir:` option to `includes` to allow choosing on which directory an included Taskfile will run:

docs/i18n/ru-RU/docusaurus-plugin-content-blog/2023-09-02-introducing-experiments.md

@@ -0,0 +1,93 @@
+---
+title: Introducing Experiments
+description: A look at where task is, where it's going and how we're going to get there.
+slug: task-in-2023
+authors:
+  - pd93
+tags:
+  - experiments
+  - breaking-changes
+  - roadmap
+  - v4
+image: https://i.imgur.com/mErPwqL.png
+hide_table_of_contents: false
+---
+
+Lately, Task has been growing extremely quickly and I've found myself thinking a lot about the future of the project and how we continue to evolve and grow. I'm not much of a writer, but I think one of the things we could do better is to communicate these kinds of thoughts to the community. So, with that in mind, this is the first (hopefully of many) blog posts talking about Task and what we're up to.
+
+<!--truncate-->
+
+## :calendar: So, what have we been up to?
+
+Over the past 12 months or so, [@andreynering][] (Author and maintainer of the project) and I ([@pd93][]) have been working in our spare time to maintain and improve v3 of Task and we've made some amazing progress. Here are just some of the things we've released in that time:
+
+- An official [extension for VS Code][vscode-task].
+- Internal Tasks ([#818](https://github.com/go-task/task/pull/818)).
+- Task aliases ([#879](https://github.com/go-task/task/pull/879)).
+- Looping over tasks ([#1220](https://github.com/go-task/task/pull/1200)).
+- A series of refactors to the core codebase to make it more maintainable and extensible.
+- Loads of bug fixes and improvements.
+- An integration with [Crowdin][crowdin]. Work is in progress on making our docs available in **7 new languages** (Special thanks to all our translators for the huge help with this!).
+- And much, much more! :sparkles:
+
+We're also working on adding some really exciting and highly requested features to Task such as having the ability to run remote Taskfiles ([#1317](https://github.com/go-task/task/issues/1317)).
+
+None of this would have been possible without the [150 or so (and growing) contributors][contributors] to the project, numerous sponsors and a passionate community of users. Together we have more than doubled the number of GitHub stars to over 8400 :star: since the beginning of 2022 and this continues to accelerate. We can't thank you all enough for your help and support! :rocket:
+
+[![Star History Chart](https://api.star-history.com/svg?repos=go-task/task&type=Date)](https://star-history.com/#go-task/task&Date)
+
+## What's next? :thinking_face:
+
+It's extremely motivating to see so many people using and loving Task. However, in this time we've also seen an increase in the number of issues and feature requests. In particular, issues that require some kind of breaking change to Task. This isn't a bad thing, but as we grow we need to be more responsible about how we address these changes in a way that ensures stability and compatibility for existing users and their Taskfiles.
+
+At this point you're probably thinking something like:
+
+> "But you use [semantic versioning][semver] - Just release a new major version with your breaking changes."
+
+And you'd be right... sort of. In theory, this sounds great, but the reality is that we don't have the time to commit to a major overhaul of Task in one big bang release. This would require a colossal amount of time and coordination and with full time jobs and personal lives to tend to, this is a difficult commitment to make. Smaller, more frequent major releases are also a significant inconvenience for users as they have to constantly keep up-to-date with our breaking changes. Fortunately, there is a better way.
+
+## What's going to change? :face_with_monocle:
+
+Going forwards, breaking changes will be allowed into _minor_ versions of Task as "experimental features". To access these features users will need opt-in by enabling feature flags. This will allow us to release new features slowly and gather feedback from the community before making them the default behavior in a future major release.
+
+To prepare users for the next major release, we will maintain a list of [deprecated features][deprecations] and [experiments][experiments] on our docs website and publish information on how to migrate to the new behavior.
+
+You can read the [full breaking change proposal][breaking-change-proposal] and view all the [current experiments and their status][experiments-project] on GitHub including the [Gentle Force][gentle-force-experiment] and [Remote Taskfiles][remote-taskfiles-experiment] experiments.
+
+## What will happen to v2/v3 features?
+
+v2 has been [officially deprecated][deprecate-version-2-schema]. If you're still using a Taskfile with `version: "2"` at the top we _strongly recommend_ that you upgrade as soon as possible. Removing v2 will allow us to tidy up the codebase and focus on new functionality instead.
+
+When v4 is released, we will continue to support v3 for a period of time (bug fixes etc). However, since we are moving from a backward-compatibility model to a forwards-compatibility model, **v4 itself will not be backwards compatible with v3**.
+
+## v4 When? :eyes:
+
+:shrug: When it's ready.
+
+In all seriousness, we don't have a timeline for this yet. We'll be working on the most serious deficiencies of the v3 API first and regularly evaluating the state of the project. When we feel its in a good, stable place and we have a clear upgrade path for users and a number of stable experiments, we'll start to think about v4.
+
+## :wave: Final thoughts
+
+Task is growing fast and we're excited to see where it goes next. We hope that the steps we're taking to improve the project and our process will help us to continue to grow. As always, if you have any questions or feedback, we encourage you to comment on or open [issues][issues] and [discussions][discussions] on GitHub. Alternatively, you can join us on [Discord][discord].
+
+I plan to write more of these blog posts in the future on a variety of Task-related topics, so make sure to check in occasionally and see what we're up to!
+
+<!-- prettier-ignore-start -->
+
+<!-- prettier-ignore-end -->
+[vscode-task]: https://github.com/go-task/vscode-task
+[crowdin]: https://crowdin.com
+[contributors]: https://github.com/go-task/task/graphs/contributors
+[semver]: https://semver.org
+[breaking-change-proposal]: https://github.com/go-task/task/discussions/1191
+[@andreynering]: https://github.com/andreynering
+[@pd93]: https://github.com/pd93
+[experiments]: https://taskfile.dev/experiments
+[deprecations]: https://taskfile.dev/deprecations
+[deprecate-version-2-schema]: https://github.com/go-task/task/issues/1197
+[issues]: https://github.com/go-task/task/issues
+[discussions]: https://github.com/go-task/task/discussions
+[discord]: https://discord.gg/6TY36E39UK
+[experiments-project]: https://github.com/orgs/go-task/projects/1
+[gentle-force-experiment]: https://github.com/go-task/task/issues/1200
+[remote-taskfiles-experiment]: https://github.com/go-task/task/issues/1317

docs/i18n/ru-RU/docusaurus-plugin-content-blog/authors.yml

@@ -3,3 +3,8 @@ andreynering:
   title: Maintainer of Task
   url: https://github.com/andreynering
   image_url: https://github.com/andreynering.png
+pd93:
+  name: Pete Davison
+  title: Maintainer of Task
+  url: https://github.com/pd93
+  image_url: https://github.com/pd93.png

docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/changelog.md

@@ -1,10 +1,18 @@
 ---
 slug: /changelog/
-sidebar_position: 9
+sidebar_position: 14
 ---
 
 # Changelog
 
+## v3.29.1 - 2023-08-26
+
+- Update to Go 1.21 (bump minimum version to 1.20) ([#1302](https://github.com/go-task/task/issues/1302) by [@pd93](https://github.com/pd93))
+- Fix a missing a line break on log when using `--watch` mode ([#1285](https://github.com/go-task/task/issues/1285), [#1297](https://github.com/go-task/task/issues/1297) by [@FilipSolich](https://github.com/FilipSolich)).
+- Fix `defer` on JSON Schema ([#1288](https://github.com/go-task/task/issues/1288) by [@calvinmclean](https://github.com/calvinmclean) and [@andreynering](https://github.com/andreynering)).
+- Fix bug in usage of special variables like `{{.USER_WORKING_DIR}}` in combination with `includes` ([#1046](https://github.com/go-task/task/issues/1046), [#1205](https://github.com/go-task/task/issues/1205), [#1250](https://github.com/go-task/task/issues/1250), [#1293](https://github.com/go-task/task/issues/1293), [#1312](https://github.com/go-task/task/issues/1312), [#1274](https://github.com/go-task/task/issues/1274) by [@andarto](https://github.com/andarto), [#1309](https://github.com/go-task/task/issues/1309) by [@andreynering](https://github.com/andreynering)).
+- Fix bug on `--status` flag. Running this flag should not have side-effects: it should not update the checksum on `.task`, only report its status ([#1305](https://github.com/go-task/task/issues/1305), [#1307](https://github.com/go-task/task/issues/1307) by [@visciang](https://github.com/visciang), [#1313](https://github.com/go-task/task/issues/1313) by [@andreynering](https://github.com/andreynering)).
+
 ## v3.28.0 - 2023-07-24
 
 - Added the ability to [loop over commands and tasks](https://taskfile.dev/usage/#looping-over-values) using `for` ([#82](https://github.com/go-task/task/issues/82), [#1220](https://github.com/go-task/task/issues/1220) by [@pd93](https://github.com/pd93)).

docs/i18n/ru-RU/docusaurus-plugin-content-docs/current/community.md

@@ -1,6 +1,6 @@
 ---
 slug: /community/
-sidebar_position: 10
+sidebar_position: 9
 ---
 
 # Сообщество