Release branch added to git

[Gavin Smith]

On Tue, Nov 08, 2022 at 07:55:44PM +0000, Gavin Smith wrote:
> > No, you just cut a new release branch.  The release branch is only for
> > a certain release or a series of releases, depending on the
> > development strategy.  Basically, as long as you expect the next
> > release to be a bugfix release, you keep developing it on the same
> > release branch, and once you decide on a feature release, you cut a
> > new release branch.  The name of the release branch can be the first
> > version released from that branch, or some variant of that.
> 
> Thanks, that makes sense.


I have added a release branch to the git repository, called "release/7.0".
Please do not commit anything to it right now if you have access.

I have gone through every branch on the master branch and cherry-picked
certain commits, although this sometimes led to merge conflicts or test
failures that I had to fix, even at this early stage of divergence.

I also don't want to commit formatting changes, such the following on
b12673c7f883bbb:

@@ -3294,11 +3309,15 @@ sub _convert($$)
           my $heading = '';
           if ($element->{'args'}->[0]->{'contents'}) {
             # It is useful to know that this is a heading formatting as
-            # the formatted heading is in the table of content, and some 
formatting
-            # may be different for that case, for instance with \texorpdfstring
-            
$self->{'formatting_context'}->[-1]->{'in_sectioning_command_heading'} = 1;
-            $heading = $self->_convert({'contents' => 
$element->{'args'}->[0]->{'contents'}});
-            
$self->{'formatting_context'}->[-1]->{'in_sectioning_command_heading'} = 0;
+            # the formatted heading is in the table of content, and some
+            # formatting may be different for that case, for instance with
+            # \texorpdfstring
+            $self->{'formatting_context'}->[-1]
+                                  ->{'in_sectioning_command_heading'} = 1;
+            $heading = $self->_convert(
+                        {'contents' => $element->{'args'}->[0]->{'contents'}});
+            $self->{'formatting_context'}->[-1]
+                                  ->{'in_sectioning_command_heading'} = 0;
           }
           my $section_cmd = $section_map{$cmdname};
           die "BUG: no section_map for $cmdname"

Please can any bug fixes avoid such formatting changes.  This is both
for our benefit and for the benefit of anybody checking the work on
the release branch (think distribution maintainers who maintain a very
limited set of patches to official releases).  I have tried
to exclude these using commands like "git checkout --patch".

131ba09f6f3e9e6 also had a lot of formatting changes.

Another question:

Commit 15ef3457ed1 (on release branch)

This led to test result changes in
tp/t/results/sectioning/unnumbered_before_top_node.pl
tp/t/results/preformatted/titlefont_in_example.pl

which weren't on the master branch - in both cases, the title from
@titlefont was lost, although @titlefont was used in an unusual context.
I assume this doesn't matter but please let me know if it does.

I have updated the version number on the release branch to 7.0.1 already,
so it should be ready to go at the time we decide to make a new release
from this branch.

I will make sure to update the po files in case of translation updates
before release, but there will be few other changes.  There are already
many changes just for this one bug and I worry that we'll lose more
confidence from users the more changes that there are.  Hopefully we
avoid users getting failures immediately after the release, like happened
last time, with less code churn near to the release.

It may be safe to update htmlxref.cnf if there are changes to be
made to that file.

While other changes since the last release may be valuable, I don't see
that they are urgent.  Please discuss it if there's anything vital that
people think that should be included.