Opening this up from #1064212: Page caching performance has regressed by 30-40% see the one metre strace from there.

At a minimum, we can not call date_default_timezone_get() with no arguments, if ini_get('date.timezone') returns something - because it will fall back to that anyway. That should save the validation in date_default_timezone_set().

Comments

catch’s picture

Title: Fix drupal_get_user_timezone() » date_default_timezone_set(), date_default_timezone_get() and strotime() all do huge syscalls

Isolated the three functions in a one off PHP file. All three load the timezones database from system.

We can probably avoid calling them all during page cache, but may have to eat this for full bootstrap.

catch’s picture

Title: date_default_timezone_set(), date_default_timezone_get() and strotime() all do huge syscalls » date_default_timezone_set(), date_default_timezone_get() and strtotime() all do huge syscalls
Status: Active » Needs review
StatusFileSize
new4.06 KB

OK here's a patch.

Adds a new function drupal_set_configured_timezone(). This sets the user or site-wide timezone, but only if it's different from the timezone configured in php.ini (or if no timezone is configured). If neither the user, site-wide, or date.timezone is set, then we allow PHP to throw the E_STRICT (soon to be E_WARNING) - we can consider mitigating that but setting a timezone on install (and in an update for D7) if date.timezone isn't set, but that's not in the patch.

Confirmed that there's no meter long syscall in strace (unless the browser sends an if-modified-since header in which case you get one from strtotime() but we can't really help that).

Status: Needs review » Needs work
Issue tags: -Performance

The last submitted patch, timezone.patch, failed testing.

berdir’s picture

Status: Needs work » Needs review

#2: timezone.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, timezone.patch, failed testing.

catch’s picture

Status: Needs work » Needs review
Issue tags: +Performance

#2: timezone.patch queued for re-testing.

mattyoung’s picture

SubScribe

dries’s picture

Status: Needs review » Needs work
+++ includes/bootstrap.inc
@@ -1943,9 +1944,26 @@ function drupal_get_user_timezone() {
+function drupal_set_configured_timezone() {

- What about calling this function drupal_set_timezone()? I'm not sure that '_configured_' part adds value.

- In the phpDoc I would explain why we want to set the timezone.

- With the patch, drupal_get_user_timezone() is only called once. It took me a while to grok this patch. I think inlining drupal_get_user_timezone() in drupal_set_(configured_)timezone() would improve readability -- might be a small clean-up. Only for D8.

catch’s picture

Status: Needs work » Needs review
StatusFileSize
new3.67 KB

Renamed the function and added some phpdoc.

I'm not 100% we want to set the timezone for the request to the user's configured timezone indiscriminately to be honest, but haven't thought through the implications. However this issue doesn't change anything in terms of functionality apart from avoiding the @ nastiness and the syscall, but tried to leave that out of the comment.

I don't mind doing the in-lining in Drupal 8, although for that I'd also like to discuss the user vs. site priority across the request as well.

Status: Needs review » Needs work

The last submitted patch, timezone.patch, failed testing.

catch’s picture

Looks like patch in #2 was committed by mistake in http://drupal.org/cvs?commit=502480

dries’s picture

I rolled back the accidental commit of #2.

bfroehle’s picture

Status: Needs work » Needs review

#9: timezone.patch queued for re-testing.

mfb’s picture

Status: Needs review » Needs work

This patch causes notices during install: Notice: date_default_timezone_set(): Timezone ID '' is invalid in drupal_set_timezone() (line 1968 of includes/bootstrap.inc).

I'd say drupal_get_user_timezone() should return a valid time zone, which NULL is not. We could check for NULL and then fallback to @date_default_timezone_get():

 $timezone = variable_get('date_default_timezone');
 return isset($timezone) ? $timezone : @date_default_timezone_get(); 

or at least use UTC, which is the last resort of date_default_timezone_get(): return variable_get('date_default_timezone', 'UTC');

By the way there's a typo in this comment, // Note that is no site-wide timezone is set should be if.

catch’s picture

Status: Needs work » Needs review
StatusFileSize
new3.71 KB

Alright Damien suggested falling back to UTC in the other issue, I've done that although not as the default value of the variable, to account for the following situation:

date.timezone is set to EST in php.ini

No timezone is configured.

We don't want to set the timezone to UTC in this case - php.ini should take precedence if there's no other preference specified anywhere.

Also fixed the typo in the comment.

mfb’s picture

Status: Needs review » Needs work

There's another problem with this approach. It doesn't account for the fact that the current value of the default time zone may be different from the date.timezone ini setting. See for example the FormatDateUnitTest, where we simulate a logged in user by setting the time zone.

The test fails if the date.timezone ini setting is America/Los_Angeles (the test user's time zone), but the logged in user running the test has some other time zone configured. The time zone needs to be changed by drupal_set_timezone(), but won't be because the test user's time zone is the same as date.timezone.

catch’s picture

Status: Needs work » Needs review
StatusFileSize
new2.58 KB

What about just removing that hunk from the patch then? Since in this case we do want to explicitly set it to something other than the default.

We might want to change drupal_set_timezone() to drupal_ensure_timezone(), but I'm not sure about that.

mfb’s picture

OK the tests pass now in my environment. One minor thing, I believe elseif is preferred vs. else if.

catch’s picture

StatusFileSize
new2.58 KB

Yes you're right, changed just the else if -> elseif in this patch.

andypost’s picture

Status: Needs review » Needs work

It looks strange a fallback to ini settings - shared hostings could have this setting unconfigured or wrong for sites they hosts.

I see no reason to use php defaults for site - maybe better use UTC.

#19 introduces a big api change drupal_get_user_timezone() now could return NULL (previously it was php defaults)

I think _drupal_init_timezone() is a better name because it actually initialize a timezone by setting it to user or system timezone...

pillarsdotnet’s picture

Status: Needs work » Needs review
StatusFileSize
new2.63 KB

Modified so that drupal_get_user_timezone() never returns NULL.

andypost’s picture

+++ includes/bootstrap.incundefined
@@ -1943,9 +1943,32 @@ function drupal_get_user_timezone() {
+/**
+ * Set the timezone for a request.
+ *
+ * This function ensures a timezone is set if it is available in either php.ini,
+ * the default timezone for the site, or user settings.
+ */
+function drupal_set_timezone() {

drupal_init_timezone() is a better name because it means just called once and drupal_set_timezone() supposes a mirror function drupal_get_timezone()

Powered by Dreditor.

mfb’s picture

I'd agree re: init, since this function isn't guaranteed to actually set the time zone (as seen in the tests).

pillarsdotnet’s picture

StatusFileSize
new2.65 KB

bikeshedding.

Whatever...

andypost’s picture

To continue bikeshedding in terms of performance.

+++ includes/bootstrap.incundefined
@@ -1943,9 +1943,32 @@ function drupal_get_user_timezone() {
-    return variable_get('date_default_timezone', @date_default_timezone_get());
+    return variable_get('date_default_timezone', ini_get('date.timezone') ? ini_get('date.timezone') : 'UTC');

ini_get() is called twice probably

 $system_timezone = ini_get('date.timezone');
  return variable_get('date_default_timezone', $system_timezone ? $system_timezone : 'UTC');

should be faster

EDIT: but this depends on PHP - memory allocation for variable could take more time then array key manipulation

Powered by Dreditor.

pillarsdotnet’s picture

Benchmarks?

catch’s picture

Version: 7.x-dev » 8.x-dev
Priority: Major » Normal
StatusFileSize
new516 bytes
new310.9 KB
new455.43 KB

I did some more testing of this using the patch from #25 on my localhost.

There is some caching of the timezone database in PHP 5.3. The first request it loads up about 50 different files, subsequent requests it looks more like this:


6045  stat("/usr/share/zoneinfo/Asia/Tokyo", {st_mode=S_IFREG|0644, st_size=331, ...}) = 0
6045  open("/usr/share/zoneinfo/Asia/Tokyo", O_RDONLY) = 10
6045  fstat(10, {st_mode=S_IFREG|0644, st_size=331, ...}) = 0
6045  mmap(NULL, 331, PROT_READ, MAP_SHARED, 10, 0) = 0x7f546cdaf000
6045  close(10)                         = 0
6045  munmap(0x7f546cdaf000, 331)       = 0
6045  stat("/usr/share/zoneinfo/Asia/Tokyo", {st_mode=S_IFREG|0644, st_size=331, ...}) = 0

However with the patch we're skipping the syscall entirely, so this is definitely worth doing, but not 'major'.

I used this file to test with (rename timezone.txt to timezone.php). Attaching strace output with and without the patch.

It's not worth doing benchmarks, but this couldn't be any more in the critical path.

catch’s picture

Issue tags: +Needs backport to D7

Can still be backported too.

droplet’s picture

PHP 5.3, 10 nodes with 10 images, load 5 times for each.

Before
=======

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 38.56    0.010000         154        65           select
 13.75    0.003565          19       189           poll
 11.91    0.003088           2      1425       995 open
 10.61    0.002752           0      7044           gettimeofday
  7.88    0.002044           5       435           close
  7.62    0.001977           5       420         5 stat
  6.52    0.001691           1      1155       195 read
  2.04    0.000530           3       200           writev
  0.89    0.000230           0       894           fcntl
  0.22    0.000057           0       200           write
  0.00    0.000000           0       235           fstat
  0.00    0.000000           0        15         5 lstat
  0.00    0.000000           0         5           socket
  0.00    0.000000           0         5           connect
  0.00    0.000000           0         6           accept
  0.00    0.000000           0         6           getsockname
  0.00    0.000000           0         5           setsockopt
  0.00    0.000000           0        10           getdents
  0.00    0.000000           0       195           times
------ ----------- ----------- --------- --------- ----------------
100.00    0.025934                 12509      1200 total






After
=======

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 25.68    0.002832           0      7020           gettimeofday
 20.38    0.002248           2      1425       995 open
 18.71    0.002063           9       235           fstat
 12.19    0.001344           3       435           close
 11.90    0.001312           1      1159       195 read
  8.09    0.000892           2       420         5 stat
  1.70    0.000188           0       870           fcntl
  1.36    0.000150           1       200           write
  0.00    0.000000           0        15         5 lstat
  0.00    0.000000           0       189           poll
  0.00    0.000000           0       200           writev
  0.00    0.000000           0        69           select
  0.00    0.000000           0         5           socket
  0.00    0.000000           0         5           connect
  0.00    0.000000           0         5           setsockopt
  0.00    0.000000           0        10           getdents
  0.00    0.000000           0       195           times
  0.00    0.000000           0         6           restart_syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.011029                 12463      1200 total
catch’s picture

Title: date_default_timezone_set(), date_default_timezone_get() and strtotime() all do huge syscalls » Remove syscalls from calling date_default_timezone_set(), date_default_timezone_get()

@droplet it looks like you have xdebug enabled as an extension - this causes a lot of calls to gettimeofday, any chance you could try again without it?

droplet’s picture

Yes, disable Xdebug reduce a bit of calls. But i think the big different it you are tested on anonymous users and Im logged.

here is the result of dsiable xdebug and anony user (load homepage with 1 node 5 times)

Before
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 72.51    0.018980         204        93           poll
  8.89    0.002327          23       100           fstat
  5.94    0.001556          15       105           writev
  4.85    0.001269           0      3424           gettimeofday
  3.84    0.001004           2       600       400 open
  2.95    0.000771           2       514        99 read
  1.03    0.000270           1       230         5 stat
  0.00    0.000000           0       105           write
  0.00    0.000000           0       205           close
  0.00    0.000000           0        15         5 lstat
  0.00    0.000000           0        20           select
  0.00    0.000000           0         5           socket
  0.00    0.000000           0         5           connect
  0.00    0.000000           0         6           accept
  0.00    0.000000           0         6           getsockname
  0.00    0.000000           0         5           setsockopt
  0.00    0.000000           0       434           fcntl
  0.00    0.000000           0        10           getdents
  0.00    0.000000           0       100           times
------ ----------- ----------- --------- --------- ----------------
100.00    0.026177                  5982       509 total


After
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 42.47    0.006285          67        94           poll
 16.33    0.002416           4       600       400 open
 12.01    0.001778           3       515       100 read
 11.25    0.001665           8       205           close
  9.03    0.001336           0      3400           gettimeofday
  4.77    0.000706           7       105           writev
  4.14    0.000613           6       100           fstat
  0.00    0.000000           0       105           write
  0.00    0.000000           0       230         5 stat
  0.00    0.000000           0        15         5 lstat
  0.00    0.000000           0        20           select
  0.00    0.000000           0         5           socket
  0.00    0.000000           0         5           connect
  0.00    0.000000           0         5           setsockopt
  0.00    0.000000           0       410           fcntl
  0.00    0.000000           0        10           getdents
  0.00    0.000000           0       100           times
  0.00    0.000000           0         6           restart_syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.014799                  5930       510 total
pounard’s picture

Just in case, I ended up on these calls by having a breakpoint in the error handler, in D7 we can do this straight forward patch (that will avoid most calls):

Replace this code (bootstrap.inc line 2212):

function drupal_get_user_timezone() {
  global $user;
  if (variable_get('configurable_timezones', 1) && $user->uid && $user->timezone) {
    return $user->timezone;
  }
  else {
    // Ignore PHP strict notice if time zone has not yet been set in the php.ini
    // configuration.
    return variable_get('date_default_timezone', @date_default_timezone_get());
  }
}

By this code:

function drupal_get_user_timezone() {
  global $user;
  if (variable_get('configurable_timezones', 1) && $user->uid && $user->timezone) {
    $timezone = $user->timezone;
  }
  else if (!$timezone = variable_get('date_default_timezone')) {
    // Ignore PHP strict notice if time zone has not yet been set in the php.ini
    // configuration.
    $timezone = @date_default_timezone_get();
  }
  return $timezone;
}

I will post a patch in D7 only bug since D8 seems to diverge too deeply with D7 at this stade.

anavarre queued 25: timezone_1064882.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 25: timezone_1064882.patch, failed testing.

andypost’s picture

Issue summary: View changes

as PHP 5.4 requirement it makes more sense to clean-up.
Also most of core use UTC:

core8$ git grep date_default_timezone_set
core/lib/Drupal/Component/Gettext/PoHeader.php:81:    // date_default_timezone_set() is called.
core/lib/Drupal/Core/Cache/TimeZoneCacheContext.php:28:    // date_default_timezone_set() is called in SessionManager::initialize(), so
core/lib/Drupal/Core/Session/SessionManager.php:152:    date_default_timezone_set(drupal_get_user_timezone());
core/lib/Drupal/Core/Session/SessionManager.php:306:    date_default_timezone_set(drupal_get_user_timezone());
core/modules/system/src/Tests/Common/FormatDateTest.php:133:    date_default_timezone_set(drupal_get_user_timezone());
core/modules/system/src/Tests/Common/FormatDateTest.php:155:    date_default_timezone_set(drupal_get_user_timezone());
core/modules/system/src/Tests/Datetime/DrupalDateTimeTest.php:103:    date_default_timezone_set(drupal_get_user_timezone());
core/modules/system/src/Tests/Datetime/DrupalDateTimeTest.php:115:    date_default_timezone_set(drupal_get_user_timezone());
core/tests/bootstrap.php:95:date_default_timezone_set('UTC');
core/vendor/twig/twig/test/Twig/Tests/Fixtures/filters/date.test:35:date_default_timezone_set('Europe/Paris');
core/vendor/twig/twig/test/Twig/Tests/Fixtures/filters/date_default_format.test:7:date_default_timezone_set('UTC');
core/vendor/twig/twig/test/Twig/Tests/Fixtures/filters/date_default_format_interval.test:9:date_default_timezone_set('UTC');
core/vendor/twig/twig/test/Twig/Tests/Fixtures/filters/date_immutable.test:18:date_default_timezone_set('Europe/Paris');
core/vendor/twig/twig/test/Twig/Tests/Fixtures/filters/date_interval.test:10:date_default_timezone_set('UTC');
core/vendor/twig/twig/test/Twig/Tests/Fixtures/filters/date_modify.test:7:date_default_timezone_set('UTC');
core/vendor/twig/twig/test/Twig/Tests/Fixtures/filters/date_namedargs.test:8:date_default_timezone_set('UTC');
core/vendor/twig/twig/test/Twig/Tests/Fixtures/functions/date.test:11:date_default_timezone_set('UTC');
core/vendor/twig/twig/test/Twig/Tests/Fixtures/functions/date_namedargs.test:7:date_default_timezone_set('UTC');
andypost’s picture

also drupal_get_user_timezone() is the only pita finally clean-up global user

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

  • Dries committed 9c44a60 on 8.3.x
    - Rollback of accidentical commit #1064882.
    
    

  • Dries committed 9c44a60 on 8.3.x
    - Rollback of accidentical commit #1064882.
    
    

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

  • Dries committed 9c44a60 on 8.4.x
    - Rollback of accidentical commit #1064882.
    
    

  • Dries committed 9c44a60 on 8.4.x
    - Rollback of accidentical commit #1064882.
    
    

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andypost’s picture

Faced with that again

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andypost’s picture

Issue tags: +Needs reroll
ilya.no’s picture

StatusFileSize
new2.7 KB

Rerolled patch from #25.

andypost’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andypost’s picture

Version: 8.5.x-dev » 8.6.x-dev

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

  • Dries committed 9c44a60 on 9.1.x
    - Rollback of accidentical commit #1064882.
    
    

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new140 bytes

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

catch’s picture

#3009377: Replace drupal_get_user_timezone with a date_default_timezone_get() and an event listener refactored this a lot, but not sure if it made things better or worse.

The issue is that date_default_timezone_set() validates the timezone it is passed, and to validate it, it has to load the list of all timezones from the operating system to check against that.

I think we can still check in TimezoneResolver::setDefaultTimeZone() whether the timezone that we would set is identical to what's already set in php.ini, and avoid setting it if so. Will need a before and after strace to confirm it actually makes a difference.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.