Please review: new wiki page with release instructions

In order to allow other people than me to make releases in the future, I tried to write down a step-by-step guide to making a release (the page is linked from the wiki homepage): https://github.com/haskell/cabal/wiki/Making-a-release I'd appreciate if people could take a look and see if there's something missing (e.g. the actual build steps using a sandbox tend to not always work, asking me to re-configure as the Cabal version changed.)

Hi Johan,
On 16 March 2015 at 08:14, Johan Tibell
[...]
Looks OK, thanks for doing this.

On Tue, Mar 17, 2015 at 8:47 AM, Mikhail Glushenkov
Hi Johan,
On 16 March 2015 at 08:14, Johan Tibell
wrote: [...]
Looks OK, thanks for doing this.
Thanks for putting that together, Johan! Is anyone doing new releases for GHC 7.10? cabal-install needs the filepath dependency bumped, at least. GHC-7.10.1-rc3 is actually shipping an unreleased version of Cabal, so I think we should release that ASAP so the final version can be included in ghc-7.10.1. I volunteer to do these releases, so if one of you has already started, please speak up! Otherwise, please alert me if you have any blocking issues; AFAIK there are none at this time. -- Thomas Tuegel

Hi,
On 17 March 2015 at 16:15, Thomas Tuegel
Otherwise, please alert me if you have any blocking issues; AFAIK there are none at this time.
There are two test cases that are failing with 7.10, but fixing them will probably only require changes to the tests themselves. I'm looking into this right now.

On Tue, Mar 17, 2015 at 4:29 PM, Mikhail Glushenkov
Hi,
On 17 March 2015 at 16:15, Thomas Tuegel
wrote: Otherwise, please alert me if you have any blocking issues; AFAIK there are none at this time.
There are two test cases that are failing with 7.10, but fixing them will probably only require changes to the tests themselves. I'm looking into this right now.
It would be great if this regression [1] could be fixed. It is causing issues with packages with custom Setup.hs files on older GHC releases. It was fixed before, but broke again. Erik [1] https://github.com/haskell/cabal/issues/2409

If someone could let me know when all the needed patches are on the 1.22
branch (and if we need both a Cabal and cabal-install release), I will make
the release and take it as an opportunity to validate the release process
instructions.
P.S. I will try the tagging Herbert suggested.
On Wed, Mar 18, 2015 at 12:14 AM, Erik Hesselink
On Tue, Mar 17, 2015 at 4:29 PM, Mikhail Glushenkov
wrote: Hi,
On 17 March 2015 at 16:15, Thomas Tuegel
wrote: Otherwise, please alert me if you have any blocking issues; AFAIK there are none at this time.
There are two test cases that are failing with 7.10, but fixing them will probably only require changes to the tests themselves. I'm looking into this right now.
It would be great if this regression [1] could be fixed. It is causing issues with packages with custom Setup.hs files on older GHC releases. It was fixed before, but broke again.
Erik
[1] https://github.com/haskell/cabal/issues/2409 _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Hi,
On 17 March 2015 at 21:43, Johan Tibell
If someone could let me know when all the needed patches are on the 1.22 branch (and if we need both a Cabal and cabal-install release), I will make the release and take it as an opportunity to validate the release process instructions.
I believe I have now fixed all the remaining issues on the 1.22 branch and we're ready for a new point release. Herbert, can you please update GHC 7.10 Cabal submodule reference to the tip of the 1.22 branch?

On 2015-03-16 at 08:14:06 +0100, Johan Tibell wrote:
In order to allow other people than me to make releases in the future, I tried to write down a step-by-step guide to making a release (the page is linked from the wiki homepage):
https://github.com/haskell/cabal/wiki/Making-a-release
I'd appreciate if people could take a look and see if there's something missing (e.g. the actual build steps using a sandbox tend to not always work, asking me to re-configure as the Cabal version changed.)
regarding # Tag the release. git tag Cabal-v$(VERSION) this only creates a lightweight Git tag which are not the recommended to be used for release-tagging. Moreover, annotated Git tags allow for (optional) gpg-signing. So I'd rather suggest to use git tag -a -s -m "Cabal $(VERSION)" Cabal-v$(VERSION) to create annotated Git tags carrying a more of meta-data, including a GPG signature. Moroever, as a practical motivation beyond giving a bit more authenticity to the release tags, tooling like git-describe or git submodule ignore lightweight tags by default. Cheers, hvr
participants (5)
-
Erik Hesselink
-
Herbert Valerio Riedel
-
Johan Tibell
-
Mikhail Glushenkov
-
Thomas Tuegel