The goal here is to reconcile the difference between GLib's 6-month
security policy and GNOME's 12-month policy (which may soon be expanded
to 13 months, gnome-build-meta#731). It's strange for GLib to be an
exception when the rest of GNOME supports two stable branches at a time.
I'm not aware of any other GNOME project with a shorter release lifetime
than GNOME itself, and it results in a situation where the previous
stable version of the GNOME runtime never receives any GLib updates,
since we stick with the same GLib version for the entire release and do
not do security backports.
But I also want to avoid creating an expectation that GLib maintainers
will do a bunch of additional backporting work, so most commits should
be out of scope. We can say maintainer discretion will be used to
determine whether a backport to the previous stable branch is warranted.
And normally, it won't be, so the goal should be no previous stable
branch releases. But occasionally we might feel a CVE is important
enough that a release really is warranted.
It’s a bit confusing to have two files called `README`, especially given
that `README.win32.md` only contains build instructions and none of the
other overview/contribution/bug reporting information that `README.md`
contains.
It feels like these would be better organised by having one top-level
`README.md`, and pointing to the Windows build instructions from there.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It’s been there for 2 years (since commit d81165216d), people have
probably got the message by now.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We hadn’t been substituting the version number in properly for a while,
so maybe just abandon that approach and rewrite the instructions to not
refer to a specific version number.
This simplifies things a bit, and means the install instructions can be
read online in GitLab.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Might make the API documentation a little easier to find from the GitLab
landing page for GLib.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The content of the section was more appropriate to the `NEWS` file, and
no longer helpful for anyone reading the `README`. The `README` is meant
to be a quick introduction to the project and how to contribute to it,
not a set of notes for packagers and distributors. That’s what `NEWS`
is.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This was mostly machine generated with the following command:
```
codespell \
--builtin clear,rare,usage \
--skip './po/*' --skip './.git/*' --skip './NEWS*' \
--write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).
Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.
There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.
If I’ve missed anything, please file an issue!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
There seems to be little point in substituting the version number into
README (using autotools). Rename it to README.md and distribute that
verbatim (with autotools and Meson) instead.
Autotools still requires that README exists, so leave a stub README file
in place which redirects people to README.md. This can be dropped when
we drop autotools support.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
