Note that there are many project that link against guile version 2 and use it and they would have to be updated. Plus, a compat package of some sort would probably have to be introduced. This is pretty much what we went through while updating from 1.8 to 2.0.

For the reference:

https://bugzilla.redhat.com/show_bug.cgi?id=678238
https://bugzilla.redhat.com/show_bug.cgi?id=868263

Latest release in 3.0.x series is now 3.0.4:

- https://ftp.gnu.org/gnu/guile/guile-3.0.4.tar.gz

Changes in 3.0.4 (since 3.0.3)

This release fixes the SONAME of libguile-3.0.so, which was erroneously
bumped in 3.0.3 compared to 3.0.2.  Distributions are strongly
encouraged to use 3.0.4 instead of 3.0.3.

Changes in 3.0.3 (since 3.0.2)

* New interfaces and functionality

** New baseline compiler

Guile's CPS-based compiler generates good code, but it takes time and
memory to do so.  For users that prioritize speed of compilation over
speed of generated code, Guile now has a new baseline compiler that goes
directly from the high-level Tree-IL to bytecode, skipping CPS and all
of its optimizations.  This compiler is used for `guild compile -O0',
and generally runs around ten times as fast as the CPS compiler.

*** New VM intrinsics to support baseline compiler

See "Intrinsic Call Instructions" in the manual.

*** Compiler support for warning and lowering passes
*** Compiler support for choosing different compilation orders

See "Compiler Tower" in the manual.  The new per-language "compiler
chooser" facility can choose different compilers based on optimization
level.

*** Better support for specifying optimization and warning levels

The procedural compilation interfaces (`compile', `compile-file', and so
on) now have #:optimization-level and #:warning-level keyword arguments,
which default to corresponding `default-optimization-level' and
`default-warning-level' parameters.  You can still specify warning and
optimization passes manually, but we think most users will find the
higher-level interfaces more robust to use.

** Faster Guile build from source

Guile now uses the baseline compiler for its bootstrap, when building
the first Scheme compiler.  Because the baseline compiler runs faster
and includes less code than the CPS compiler, Guile takes less time to
build.

** New 'pipeline' procedure in (ice-9 popen)

The 'pipeline' procedure provides a simple way to spawn command pipeline
as one would do in a shell.

** Refreshed bitvector facility

See "Bit Vectors" in the manual, for more on all of these.

*** New bitvector-count, bitvector-count-bits, bitvector-position
    procedures

These replace the wonky "bit-count", "bit-count*", and "bit-position"
procedures.

*** New bitvector-bit-set?, bitvector-bit-clear? procedures

These replace bitvector-ref.  The reason to migrate is that it's an
opportunity be more efficient in 3.0 (because the new procedures only
work on true bitvectors, and not generic bit arrays), easier to read (no
need for 'not' when checking for false bits), and more consistent with
other bitvector procedures.

*** New bitvector-set-bit!, bitvector-clear-bit! procedures

These replace bitvector-set!, for similar reasons as the bitvector-ref
replacement above.

*** New bitvector-set-all-bits!, bitvector-clear-all-bits! procedures

These replace bitvector-fill!.

*** New bitvector-flip-all-bits! procedure

This replaces bit-invert!.

*** New bitvector-set-bits!, bitvector-clear-bits! procedures

These replace the wonky "bit-set*!" procedure.

* Bug fixes

** statprof reports the names of primitives

Previously statprof would show strings like "anon #x1234" for primitives
written in C.

** Compiler reduces 'equal?' when passed a character literal

The compiler now properly reduces expressions such as (equal? c #\x) to
(eq? c #\x).  This was not the case in 3.0.2, which could lead to slower
code, especially in 'match' expressions with many clauses with with
character literals.

** JIT bugs on ARMv7 have been fixed
   (<https://bugs.gnu.org/40737>,
    <https://gitlab.com/wingo/lightening/-/issues/12>)

** 'http-get', 'http-post', etc. now honor #:verify-certificates?
   (<https://bugs.gnu.org/40486>)

** web: Accept URI host names consisting only of hex digits
   (<https://bugs.gnu.org/40582>)

** (web http) parser recognizes the CONNECT and PATCH methods

** Initial revealed count of file ports is now zero
   (<https://bugs.gnu.org/41204>)

* New deprecations

** Old bitvector interfaces deprecated

See "Bit Vectors" in the manual, for details on all of these
replacements.

*** bit-count, bit-position

Use bitvector-count or bitvector-position instead.  

*** bitvector-ref

Use 'bitvector-bit-set?' or 'bitvector-bit-clear?' instead.

*** bitvector-set!

Use 'bitvector-set-bit!' or 'bitvector-clear-bit!' instead.

*** bitvector-fill!

Use 'bitvector-set-all-bits!' or 'bitvector-clear-all-bits!' instead.

*** bit-invert!

Use 'bitvector-flip-all-bits! instead.

*** bit-set*!

Use 'bitvector-set-bits!' or 'bitvector-clear-bits!' instead.

*** bit-count*

Use 'bitvector-count-bits' instead, subtracting from 'bitvector-count'
on the mask bitvector if you are counting unset bits.

*** Accessing generic arrays using the bitvector procedures

For the same efficiency reasons that use of 'vector-ref' on generic
arrays was deprecated in Guile 2.0.10, using 'bitvector->list' and
similar procedures on 1-dimensional boolean-typed arrays is now
deprecated.  Use 'array-ref' and similar procedures on arrays.

*** scm_istr2bve

This C-only procedure to parse a bitvector from a string should be
replaced by calling `read' on a string port instead, if needed.

Hi Anton,
I know about this. I am updating packages which depend on old versions
of guile so we could remove some of them and introduce 3.0.4.

When TeXmacs package will be able to run on guile-2.x i will remove
compat-guile-1.8 package and shift available versions of guile in
Fedora to 2.0, 2.2, 3.0. This week i also rebuild autogen with
guile 2.2, so i'm pushing towards an upgrade as much as i can.
I did not package guile-3.0.4 yet, because i think that having
4 versions of guile is too many.
Please be patient.

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

I opened an issue in Texmacs upstream to track the porting progress: https://github.com/texmacs/devel/issues/9

Two months passed since I opened this issue in TeXmacs, no answer, no relevant commits in their repository. 
I don't think they will change any time soon, they seem to stuck with Guile 1.x forever.

Maybe it worth to use bundled Guile just for TeXmacs while the rest of ecosystem uses the modern Guile 3.x versions?

(In reply to Anton Kochkov from comment #7)
> Two months passed since I opened this issue in TeXmacs, no answer, no
> relevant commits in their repository. 
> I don't think they will change any time soon, they seem to stuck with Guile
> 1.x forever.
> 
> Maybe it worth to use bundled Guile just for TeXmacs while the rest of
> ecosystem uses the modern Guile 3.x versions?

Unfortunately the issue was open in a "non-official" place so it got unnoticed. The official TeXmacs development is hosted at savannah.gnu.org and bugs/requests should be posted there. Anyway I just noticed the request and also this discussion. I'm part of the developer team of TeXmacs, let me describe the current situation. First Guile-3 is parallel installable to Guile-2 as far as I understand, so there should be not problem to have both packages on the same system. Second, unfortunately going from 1.8 to 2 is very different than going from 2 to 3. TeXmacs is not the only project with this problem, indeed Lilypond has the same problem and as far as I know they are still with Guile 1.8 too. See here https://lists.gnu.org/archive/html/guile-devel/2021-03/msg00030.html for a recent discussion. There are also people trying to push a Guile 1.8.9 version see here https://lists.gnu.org/archive/html/guile-user/2021-03/msg00026.html . The main reason is that for many program is both difficult and not clear if a passage to Guile-2/3 would be feasible. Speed for interactive applications (i.e. where pre-compilation is not possible) is not so great and Guile 2/3 is a *very* different language from Guile 1.8, due to the different semantic generated by having two evaluation phases (expansion / evaluation) instead of the immediate interpretation semantics of Guile 1.8. In particular this last problem causes that it is not obvious to port TeXmacs to Guile 2/3 and will require large changes which we are still not able to do. Also it is not clear that we *can* rely on Guile 3 performance wise, more tests are needed. The reason is that we execute very frequently new code (generated by macros), which cannot be precompiled and if this is not fast enough then the user will notice sizeable slowdowns which we find unacceptable. So for the time being the plans are to stick to Guile 1.8. We are aware that this causes problem to distributions but we do not have an alternative strategy, I'm sorry. We are working on this problem, I wrote a blog post here https://texmacs.github.io/notes/docs/scheming.html detailing the current situation and we have a development branch here for guile 3: https://github.com/mgubi/texmacs/tree/guile3 which runs but still is not ready for production (in particular the bootstrap of the program cannot be done yet in compiled mode so is ***very*** slow, kind x100 time slow...). So you see, situation is not as clear as it seems on the paper. Guile 1.8 is a very nice program and is difficult to replace it reliably with Guile 3.0 as far as we are concerned (and seems also Lilypond is in the same situation). My wish is that you keep Guile 1.8 for some time still. If this is not possible one can compile TeXmacs by linking statically Guile 1.6 (which still works and it is small enough). If you are interested you can contact the texmacs-dev mailing list  for details on how to do it.

Latest Guile version now is 3.0.7 

https://ftp.gnu.org/gnu/guile/guile-3.0.7.tar.gz


Changes in 3.0.7 (since 3.0.6)

* New interfaces and functionality

** More O_* POSIX constants are now defined in Scheme

Guile now defines constants such as `O_NOFOLLOW', `O_CLOEXEC',
`O_TMPFILE', and more on platforms that support them.  These may be
passed as arguments to procedures such as `open' and `open-fdes'.

* Bug fixes

** Fix bugs introduced in 3.0.6 with Scheme `read` re-write
** Fix deadlock after `primitive-fork' (#41948)
** Fix duplicates handlers for interfaces that use interfaces (#43025)
** Fix compile-psyntax.scm for (language tree-il canonicalize) removal
** Fix prompt compilation bug (#48098)
** Fix R7RS include-library-declarations, cond-expand (#40252)
** Fix --enable-mini-gmp on FreeBSD and other targets
** Fix excessive compile times for vectors >16k elements long
** Fix use of literal tree-il as source language (#45131)
** Fix SRFI-64 test-end to not remove globally-installed test runner

Changes in 3.0.6 (since 3.0.5)

* Notable changes

** Reimplement dynamic library loading ("dlopening") without libltdl

Guile used to load dynamic libraries with libltdl, a library provided by
the Libtool project.

Libltdl provided some compatibility benefits when loading shared
libraries made with older toolchains on older operating systems.
However, no system from the last 10 years or so appears to need such a
thick compatibility layer.

Besides being an unmaintained dependency of limited utility, libltdl
also has the negative aspect that in its search for libraries to load,
it could swallow useful errors for libraries that are found but not
loadable, instead showing just errors for search path candidates that
are not found.

Guile now implements dynamic library loading directly in terms of the
standard "dlopen" interface, providing a limited shim for platforms with
similar functionality exposed under different names (MinGW).

This change has a few practical impacts to Guile users.  There is a new
library search path variable, `GUILE_EXTENSIONS_PATH'.  Also, errors when
loading a library fails now have better errors.  And Guile no longer has
a libltdl dependency.

Although Guile no longer uses libltdl, for backwards compatibility Guile
still adds `LTDL_LIBRARY_PATH' to the loadable library search path, and
includes ad-hoc logic to support uninstalled dynamically loadable
libraries via also adding the ".libs" subdirectories of
`LTDL_LIBRARY_PATH' elements.  See "Foreign Libraries" in the
documentation for a full discussion.

** Fix important incompatibility with GnuTLS

Guile uses the GNU multi-precision (GMP) library to implement
arbitrary-precision integers (bignums) and fractions.  Usually Guile is
built to dynamically link to libgmp.  In this configuration, any other
user of GMP in the process uses the same libgmp instance, with the same
shared state.

An important piece of shared state is the GMP allocator, responsible for
allocating storage for the digits of large integers.  For Guile it's
most efficient to install libgc as the GMP allocator.  That way Guile
doesn't need to install finalizers, which have significant overhead, to
free GMP values when Guile bignums are collected.  Using libgc to
allocate digits also allows Guile's GC to adequately measure the memory
cost of these values.

However, if the Guile process is linked to some other user of GMP, then
probably the references from the other library to GMP values aren't
visible to the garbage collector.  In this case libgc could prematurely
collect values from that other GMP user.

This isn't theoretical, sadly: it happens for Guile-GnuTLS.  GnuTLS uses
GMP, and so does Guile.  Since Guile 2.0.4, Guile has installed libgc as
the GMP allocator, so since then, Guile-GnuTLS has been buggy.

Therefore, the default is now to not install libgc as the GMP allocator.
This may slow down some uses of bignums.  If you know that your Guile
program will never use a library that uses GMP, you can set the
GUILE_INSTALL_GMP_MEMORY_FUNCTIONS=1 in your environment.  Guile sets
this environment variable when building Guile, for example.  See
"Environment Variables" in the manual, for more.

In some future, Guile may switch to GMP's more low-level "MPN" API for
working with bignums, which would allow us to regain the ability to use
GC-managed digit storage in all configurations.

** New build option: --enable-mini-gmp

For some users, it would be preferable to bundle a private copy of the
GMP bignum library into Guile.  Some users would like to avoid the extra
dependency.  Others would like to use libgc to manage GMP values, while
not perturbing the GMP allocator for other GMP users.

For these cases, Guile now has an --enable-mini-gmp configure option,
which will use a stripped-down version of GMP, bundled with Guile.  This
code doesn't have all the algorithmic optimizations of full GMP, but
implements the same API in a basic way.  It can be more optimal in a
Guile context, given that it can use libgc to allocate its data.

Note that a build with --enable-mini-gmp is not ABI-compatible with a
"stock" build, as functions that use GMP types (scm_to_mpz,
scm_from_mpz) are not exported.

Thanks to Niels Möller and other GMP developers for their mini-gmp
implementation!

** New `read' implementation in Scheme

Guile's `read' procedure has been rewritten in Scheme.  Compared to the
C reader (which still exists for bootstrapping reasons), the new
implementation is more maintainable, more secure, more debuggable, all
while faithfully reproducing all quirks from Guile's previous reader
implemented in C.  Also, the Scheme reader is finally compatible with
suspendable ports, allowing REPL implementations to be built with
lightweight concurrency packages such as the third-party "Fibers"
library.  Calls to `read' from Scheme as well as calls to `scm_read'
from C use the new reader.

The Scheme implementation is currently about 60% as fast as the
now-inaccessible C implementation, and we hope to close the gap over
time.  Bug reports very welcome.

** Scheme compiler uses `read-syntax' for better debugging

The new Scheme reader also shares implementation with the new
`read-syntax' procedure, which annotates each datum with source location
information.  Guile's compiler can use this to provide better
source-level debugging for Scheme programs.  Note that this can slightly
increase compiled file sizes, though this is mitigated by some assembler
optimizations.

** Syntax objects record source locations

When compiling a file that defines a macro, the output will usually
include a number of syntax objects as literals.  Previously, these
literals had no source information; now they do.  This should improve
debugging.

** Optimized run-time relocations

The code that patches references between statically-allocated Scheme
data has been optimized to be about 30% shorter than before or so, which
can significantly decrease compiled file size and run-time
initialization latency.

** Optimized calls to known functions

For calls where the callee is within the compilation unit, Guile can now
skip the argument count check.

** Reduce code size for calls to module variables

All calls to a given exported or private variable from a module now
dispatch through the same trampoline function.  This reduces code size.

** Updated Gnulib

The Gnulib compatibility library has been updated, for the first time
since 2017 or so.  We expect no functional change but look forward to
any bug reports.

* New interfaces and functionality

** `call-with-port'

See "Ports" in the manual.

** `call-with-input-bytevector', `call-with-output-bytevector'

See "Bytevector Ports" in the manual.

** `GUILE_EXTENSIONS_PATH' environment variable.

See "Environment Variables" in the manual.

** `mkdtemp' and `mkstemp'

See "File System" in the manual.  There is still `mkstemp!' but we
recommend that new code uses `mkstemp', which does not mutate the
contents of the "template" argument string.  Instead for `mkstemp' you
get the name of the newly-created file by calling `port-filename' on the
returned port.

** `(system foreign-library)' module

See the newly reorganized "Foreign Function Interface", for details.
These new interfaces replace `dynamic-link', `dynamic-pointer' and
similar, which will eventually be deprecated.

** `read-syntax'

See "Annotated Scheme Read" in the manual.

** `quote-syntax'

See "Syntax Case" in the manual.

** `syntax-sourcev'

See "Syntax Transformer Helpers" in the manual.

* Optimizations

** eof-object?
** R6RS vector-map, vector-for-each

* Bug fixes

** Fix reverse-list->string docstring
** Fix R7RS "member" result when no item found
** Fix make-transcoded-port on input+output ports
** Fix (ice-9 ftw) on filesystems where inode values are meaningless
** Fix many bugs that prevented Guile from building on MinGW
** Fix many bugs that prevented Guile from building on MinGW64
** Fix many bugs that prevented Guile's test suite from running on MinGW
** Fix srfi-69 merge-hash
** Fix suspendable-ports implementation of get-bytevector-some!
** Fix overread in string-locale<?, string-locale-ci<?, and friends
** Fix handling of parameter lists to elisp defun to allow nil
** Fix closure-conversion bug for SCC with no free vars and one not-well-known function
** Fix error when < passed non-real value
** Fix bug in which exported and private names in a used module could alias each other
** Fix bug with slot options in redefinable GOOPS classes
** Fix bugs regarding port buffering for TLS connections in web client

Thanks to Vasilij Schneidermann, Andrey Ivanov, Rob Browning, Erik
Dominikus, Göran Weinholt, Michael Gran, Andrew Whatson, Ricardo
G. Herdt, Jan Nieuwenhuizen, David Thompson, and abcdw.

* New deprecations

** `dynamic-unlink'

This function now has no effect; Guile will not unload dynamically
linked modules, as that can destabilize the system.

* Incompatible changes

** `call-with-output-string' closes port on normal exit

This procedure used to leave the port open, even though there was no
useful way to access it.  Now we clean it up more promptly, disposing
any possible associated iconv descriptor.

Changes in 3.0.5 (since 3.0.4)

* New interfaces and functionality

** O(1) compilation of `case' and related expressions

Guile now optimizes chains of eq? comparisons to constants, resulting in
O(1) dispatch time, regardless of the length of the chain.  This
optimization is also unlocked in many cases for `match' expressions with
many similar clauses whose first differentiator are constants.

** New (ice-9 copy-tree) module

This module includes the `copy-tree' procedure that was previously
implemented in C and present in the default `(guile)' module.  See
"Copying" in the manual.

** New warning: use-before-definition

This analysis, enabled at `-W1', issues warnings for programs that use
top-level variables before they are defined.

** New warning: non-idempotent-definition

This analysis, enabled at `-W1', issues warnings for programs that whose
use of a variable is ambiguous.  For example, in the program:

  (define saved-add +)
  (define + error)

The intention would seem to be to "save" the value of the base `+'
procedure, then override it locally.  However if this program is ever
loaded twice, then the second time it is loaded, `+' will be taken from
the local binding instead of the import.  Users that want this kind of
behavior should either use lexical bindings instead of top-level
bindings, or otherwise rename important clobbered bindings via modules.

* New deprecations

** `copy-tree' in the default environment, and `scm_copy_tree' from C

Import the `(ice-9 copy-tree)' module instead.

** `unbound-variable-analysis`, `macro-use-before-definition-analysis`

These bindings from `(language tree-il analyze)' are replaced by the
use-before-definition analysis, which powers a number of warnings.  Use
`make-use-before-definition-analysis', but note that these interfaces
are quite intimate parts of the compiler!

* Incompatible changes

** `copy' read-option removed

This read option would include a copy of the source expression in the
source-properties of each subexpression.  This option has always been
off by default and lost most of its use value with the switch to a
compiler in Guile 2.0.

Seems like this might be resolved. I just noticed an Aisleriot pulling in a guile30 package, but it seems to have been available in F35 for a while: https://koji.fedoraproject.org/koji/buildinfo?buildID=1810587

I've done a bunch of work to move packages from guile 2.0 -> 2.2 and I don't believe we have any more dependencies (according to dnf repoquery) on guile 2.0 so I think we can move to guile 3.x

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13.

Fedora Linux 35 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.