Sounds good to me. I have attached an updated copy of doc/releases.md,
which contains some notes I made during the last release. There were a
number of missing or poorly documented steps.
allan
On Sun, Jan 21, 2024 at 2:34 PM Ralph Little wrote:
> Hi,
> So it looks like we will do a 1.3.0 release.
> I propose a fairly quick timeline since there isn't a lot of critical
> stuff waiting to go in it. The only thing that I am aware of is the
> longstanding problem for macOS USB support and I think we have a partial
> solution for that which should push them on.
>
> Allan did the release last time, and perhaps I can go through the process
> this time so that I am familiar. Are you OK with that Allan?
>
> 1) Code freeze: 1 week from now (28th January), I will create a release
> branch and MRs targeted for the release should target that branch. Anything
> else not intended for the release can still target master. I will send out
> an email asking for translations after regenerating po files. During this
> time, we will not normally accept functional enhancements but exceptions
> will be considered in an emergency or if it is very safe.
>
> 2) Release: 2 weeks later (11th February) we will cut the release. I will
> also do a PPA release for our Ubuntu users.
>
> Cheers,
> Ralph
>
--
"well, I stand up next to a mountain- and I chop it down with the edge of
my hand"
---
Copyright: © 2023 SANE Project
SPDX-License-Identifier: CC-BY-SA-4.0
---
# Creating A New `sane-backends` Release
This file summarizes most points to pay attention to when planning for
a new `sane-backends` release. Content has been checked while working
on `$old_version` and getting ready for `$new_version`, where:
``` sh
old_version=1.1.1
new_version=1.2.1
```
## Timetable
It is easiest to pick a release date well in advance so everyone knows
what to expect. Ignoring security bug fix releases, `sane-backends`
has been released on a roughly half-yearly schedule since `1.0.28`.
Once you pick a date (and time), say `DT`, the planning is simply a
matter of counting back from there:
- `$DT - 35 days`: **schedule announcement** including the timetable.
- `$DT - 21 days`: **feature freeze** branch, only bug fixes and translations allowed.
- `$DT - 14 days`: **code freeze** only translations allowed.
- `$DT - 0 days`: **release** :confetti_ball:
Feel free to adjust the offsets if that works better. Also, pinging
on the mailing list well in advance, say two, three months, about a
suitable date for everyone involved is a good idea.
> If you mention time of day, on the mailing list, in issues or merge
> requests, use UTC times and mention that, e.g. 09:00 UTC. People
> are in time zones all over the place and converting to and from UTC
> should be relatively easy for everyone. Converting from other
> time zones is generally cumbersome, even without things like DST.
## Schedule Announcement
Part of the announcement of the release schedule is a request from translators
to update translations. You can make this easier on them, by syncing the po
files before the announcement:
make -C po update-po
git add po
git commit -m "Update po files for sane-backends-$new_version release"
git push
Send an announcement to the `sane-devel` mailing list announcing the schedule.
Make sure to request translators to checkout the current master branch, and
produce updates (preferably before feature freeze starts).
## Feature Freeze
A separate branch for the upcoming release is created in the repository. This marks the point when
the code for the release effectively enters a feature freeze and no new features will be added to
the release branch.
At this point, no new text strings are likely to get added to the release branch. That means that
po files should be stable, and it is a good idea to again sync the po files for translators. If
we do this before we make the branch, we will not have to repeat it in both the master and release
branches.
make -C po update-po
git add po
git commit -m "Update po files for sane-backends-$new_version release"
git push
Name the branch in the format of `release-1.2.x` so that it's clear that further bugfix releases
will happen on that branch.
Here, we create the local branch, send it to remote, and then set our local to track the remote:
``` sh
release_branch=release-1.2.x
git branch $release_branch
git checkout $release_branch
git push origin $release_branch
git branch -u origin/$release_branch
```
For backends added since the `$old_version`, make sure that its
`.desc` file includes a `:new :yes` near the top. You can find such
backends from the list of added files with:
``` sh
git ls-files -- backend | while read f; do
git log --follow --diff-filter=A --find-renames=40% \
--format="%ai $f" $old_version..$release_branch -- "$f"
done | cat
```
Occasionally, you may notice changes that have not been documented,
either in a `.desc` file or a manual page. Now is a good time to
rectify the omission.
