Re: Next release of manpages-l10n
Hello all,
I've just released v4.2.0, I've succeeded to figure it out how this
works. It was simpler than expected, see below.
Am So., 4. Okt. 2020 um 10:29 Uhr schrieb Jean-Philippe MENGUAL
<jpmengual@debian.org>:
>
>
> Le 04/10/2020 à 07:32, Helge Kreutzmann a écrit :
> > Hello Jean-Philippe,
> > On Sat, Oct 03, 2020 at 08:25:36PM +0200, Mario Blättermann wrote:
> >> Am Sa., 3. Okt. 2020 um 20:03 Uhr schrieb Jean-Philippe MENGUAL
> >> <jpmengual@debian.org>:
> >> You don't have to be an »uploading developer« for releasing an
> >> upstream tarball of manpages-l10n. This is only for Debian packaging.
> >> Upstream releasing and downstream packaging do not necessarily have to
> >> be linked to each other. Of course, this can be done by different
> >> persons, although manpages-l10n is still to be considered as a Debian
> >> project, but meanwhile distribution-agnostic.
> >
> > I strongly concour with Mario.
> >
> > manpages-l10n uses Debian infrastructure, but it is not a Debian
> > project, but rather an upstream one.
> >
> > There are various downstreams as Mario gave a nice overview.
> >
> > One of them is Debian, where currently Tobias is the Maintainer.
> > Unfortunately Tobias is not able to maintain both the Debian
> > downstream and the upstream project as he used to be.
> >
> > Mario is very involved in getting the upstream part working again
> > (which I stronly support where I technically can) and we are
> > discussing this (albeit very slowly) with Tobias.
> >
> > I offered to take over the Debian downstream part, which I technically
> > could (though reviewing the steps once more especially for backports
> > could be helpful), but I'm no developer, so Tobias would need to grant
> > me the permission for uploads. This has been proposed to Tobias, so I
> > hope the Debian side gets going properly again as well.
> >
> > But the big issue are the upstream releases.
>
> Can Tobias, Mario and whoever write a step-to-step doc (eg. in
> CONTRIBUTING.md) with administrative commands and actions needed to be a
> release manager? Perhaps I can help if I have the process and the git
> commands written, if I know who announce the next release to, etc. In
> case I have technical issues, I may find help on the mailing lists. But
> this initial doc is absolutely needed to help a non-tech person to do
> the release management I think.
>
Preparing a release is quite simple:
Search with grep for the current version number. You'll get some
occurrences in »configure«, »configure.ac«, »CHANGES.md« etc.
(Don't bother with the version numbers in .po file headers)
Replace the old version number with the new one.
Write an appropriate entry in CHANGES.md.
Run »autoreconf« (don't know if this is really needed).
Commit and push the changes.
Then, use the Gitlab web interface for creating the tag:
In the sidebar on the left, click on »Tags«. In the tag overview on
the right, click on the »New tag« button.
Fill the mask with the values for the new release:
Tag name: v4.2.0
Create from: master (just leave this entry untouched)
Message: Release 4.2.0
That's all. Users and downstream packagers can now download the
tarball from the known location. I'll add these steps to
CONTRIBUTING.md soon.
Usually I tell then the Mageia, Opensuse and Archlinux packagers about
the new release (Fedora has its own notification service for upstream
releases). Regarding Debian, someone needs to pick up the package
maintenance.
Best Regards,
Mario
Reply to: