[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Upcoming 0.26.0, please review release notes

From: Ivan Vučica
Subject: Re: Upcoming 0.26.0, please review release notes
Date: Sat, 09 Dec 2017 13:43:30 +0000

This is a very good point.

I did not spot that the annotated tag’s object did not contain the correct ANNOUNCE. It certainly was supposed to be sourcing the file as it is on the disk, and I am not sure how it used the older revision of the file to tag the newer commit. Maybe Make did not rebuild the temp file. If this is correct, I’ll address it in -make.

I don’t think -make *needs* a release; the change I made is only useful to people who want to cut releases using Git. It’s not super important for other dependencies.

I have no opinion on whether we need a synced release; -gui is certainly in need of it as Debian is blocked from pulling in even 0.25.1.
sub, 9. pro 2017. u 13:28 Fred Kiefer <address@hidden> napisao je:
Hi Ivan,

all of this looks great to me. One thing I did not understand is why the Announce file in the tag is less complete, then on the master branch. But this surely will be corrected for the real release.
I still would like to see a coordinated release of base, gui and back. With make I am a bit unsure. Your latest change there seems to be the only commit for this module. So it is up to decide whether a release is needed.

Thank you for working on this,

> Am 07.12.2017 um 23:57 schrieb Ivan Vučica <address@hidden>:
> cURLable text file available here, in case you wish neither to clone
> the repo nor use the GitHub web UI:
> Now, further remarks:
> This release will be created using something called an "annotated tag"
> in Git. Annotated tags are not merely references to a commit, but they
> are otherwise objects in their own right, and have an author, date and
> a commit message of their own.
> GitHub (and probably other similar systems) expose them as 'releases'.
> Instead of having to attach a message using web UI, the tag commit
> message will be used. This means whatever we deploy as a tag commit
> message, we can take out when we move from GitHub.
> As a less practical, but more of a fun thing, I won't be creating just
> an annotated tag but a GPG-signed annotated tag. This means users can
> use 'git tag -v gui-0_26_0' to check that the signer claims this
> release is genuine. I will be using my personal GPG key for this, as
> that will be appropriately displayed in systems that support
> displaying that a tag has been correctly signed. If I were to use the
> GNUstep Maintainers key, it would not be appropriately displayed as
> released by my account. Actual signature *will* be performed with the
> correct maintainer GPG key!
> You can see all this in action here:
> (You may observe that this is not pushed to the mainline repo. That is
> because this is *not* yet the 0.26.0 release; I've tagged it only for
> preview. Actual tag will be pushed to the main GNUstep repository for
> libs-gui. I've manually marked the release as pre-release.)
> Preview, prerelease, not-actually-0.26.0 tarball and
> personally-signed-.sig (use curl -L to download):
> To facilitate cutting this release, I have updated gnustep-make. It
> now has targets 'git-tag' and 'git-dist' which behave similar to
> 'svn-tag' and 'svn-dist', except that they operate on local repo only.
> They use annotated tags, support keysigning and using a text file as
> the source for the tag commit message. All tagging and releasing
> operations are on the local repository; pushing tags to a public
> repository is left to the developer invoking these convenience
> commands.
> I've opted to ask for a review of the changes to gnustep-make in case
> I use some incompatible feature of GNU Make, or if it's
> incomprehensible. If there are no significant comments, I will merge
> this shortly.
> or
> It should affect only people using gnustep-make to cut releases for
> their software.
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]