toggle quoted messageShow quoted text
Instead of using a pivotal tap, why don't we create a cloudfoundry tap for
the open source bits? Shannon raised this as an issue on the CLI repo
and I think it makes a lot of sense.
Not only will it put the tools in the proper namespace, it's easy to
provide push access for the appropriate development teams.
On Wed, Dec 23, 2015 at 7:34 AM, Stevo Slavić <sslavic(a)gmail.com> wrote:
Last time I requested CF CLI release to be bumped on homebrew tap, it got
closed by Ben https://github.com/pivotal/homebrew-tap/issues/62 saying
they expect CF CLI team to provide PR. Maybe creation of that PR can be
automated, so next time we read release notes community will be able to
find CF CLI release also there.
On Wed, Dec 23, 2015 at 1:15 PM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
Thanks for the feedback!
The release process tends to take about 4 hours and we started the
release process in the afternoon so we didn’t get to updating homebrew on
the same day.
It’s the first thing the team will do tomorrow morning.
I didn’t want to postpone sending the announcement.
I’m not sure what is involved in preparing the homebrew tap PR and who
can accept it when. I can ask around, maybe we can ping someone when we
submit the PR and get it fast-tracked.
We are also incrementally working on speeding up our release process and
automating more steps.
This time for example you may have noticed that the release notes below
and the changelog on GitHub are the same, and in MarkDown format.
They used to be produced separately, one in a Google Doc based on the
stories in Tracker and the other from the commit log.
On the other hand, we introduced a new manual step of digitally signing
the Mac OS X package. We will automate this when we have a solution to
how/where to store the developer’s certificate used for signing in a secure
Cloud Foundry CLI PM
*From:* Stevo Slavić [mailto:sslavic(a)gmail.com]
*Sent:* Wednesday, December 23, 2015 9:08 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* [cf-dev] Re: CF CLI v6.14.1 Released Today
Thanks for the release and fixes!
One improvement idea - please consider making it part of the release
process to provide pull request for
Maybe it's already part of the process but delay between announcement and
cf cli available on homebrew is longer than a day. IMO ideally pull request
is at least created if not also merged before announcement of release is
On Wed, Dec 23, 2015 at 3:39 AM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
The CF CLI team just cut 6.14.1. Binaries and link to release notes are
Highlights of this release include:
Install Experience Improvements
- Mac OS X installer is now digitally signed with a Foundation
certificate, so CLI can be installed without needing to bypass security
features. (Similar experience on Windows will be addressed soon.)
- Mac OS X installer now includes the correct CLI release version and
package size in distribution manifest
- Debian installer now denotes the correct package size
- push now deploys apps with jars generated with Spring Boot 1.3.0
that embed a script at the start of the jar file (#411
- push now deploys apps with >64KB read-only files (#685
- push no longer fails on Windows with >260 character paths that are
specified in .cfignore (#564
- push no longer continues traversing folders specified in .cfignore (
- push now displays a user friendly message when no application files
found (#687 <https://github.com/cloudfoundry/cli/issues/687>)
- push now uses a CF Foundation buildpack as example in help text for
- ssh no longer swallows execution result when invoked repeatedly
with -c option (#702 <https://github.com/cloudfoundry/cli/pull/702>)
- auth now displays an error message in case of a 502 HTTP error
- help no longer includes redundant BUILD TIME section
- delete-quota now displays correct help text for -f option (#715
- purge-service-instance now returns a meaningful error message when
targeting a CF release that does not support purging service instances (
Plugin Framework Changes
- The Domain field of the application model returned by GetApp is now
properly populated (#699
- CF Doctor Plugin: https://github.com/emirozer/cf-doctor-plugin
Cloud Foundry CLI PM