FAQ
With the release coming "around" June 10th. :) Will that resume the
practice of creating "final" v2 releases in cf-release?

I would really like to be able to base my internal releases on v2 releases
I know you guys have tested and deployed to production yourselves.

Thanks,
Mike

Search Discussions

  • Dr Nic Williams at Jun 6, 2013 at 4:42 pm
    +1


    I have documented many good benefits for restoring to the universe the blessed wonders of final releases. Mike's is one of them.

    I did hear from a guy who knows a guy that a v2 final release might be cut with the public GA launch of cf.com. But perhaps I hear what I want to hear :)
  • Mike Youngstrom at Jun 6, 2013 at 5:06 pm
    Actually, after thinking about it. For our use case it would be best for
    us if we could just get a tag in the cf-release repo. Since we do our own
    final releases that include our custom jobs, a tag only would actually be
    perfect. It would simplifies our cf-release merges to not have to deal
    with "final" conflicts.

    Perhaps if tags only are provided in the main cf-release repo then it would
    still be simple for a group of public users like Dr. Nic to fork cf-release
    and provide their own final releases based off the cf-release tags?

    Mike

    On Thu, Jun 6, 2013 at 10:41 AM, Dr Nic Williams wrote:

    +1

    I have documented many good benefits for restoring to the universe the
    blessed wonders of final releases. Mike's is one of them.
    I did hear from a guy who knows a guy that a v2 final release might be cut
    with the public GA launch of cf.com. But perhaps I hear what I want to
    hear :)
  • Dr Nic Williams at Jun 6, 2013 at 5:09 pm
    Can I propose that you don't fork cf-release; rather have a separate release for the jobs you customised? Then you merge them during deploy time as a composite release. Just a theory. Haven't don't it personally. But I'm very aware of the unforkable nature of bosh releases.
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic
    On Thu, Jun 6, 2013 at 10:06 AM, Mike Youngstrom wrote:

    Actually, after thinking about it. For our use case it would be best for
    us if we could just get a tag in the cf-release repo. Since we do our own
    final releases that include our custom jobs, a tag only would actually be
    perfect. It would simplifies our cf-release merges to not have to deal
    with "final" conflicts.
    Perhaps if tags only are provided in the main cf-release repo then it would
    still be simple for a group of public users like Dr. Nic to fork cf-release
    and provide their own final releases based off the cf-release tags?
    Mike
    On Thu, Jun 6, 2013 at 10:41 AM, Dr Nic Williams wrote:
    +1

    I have documented many good benefits for restoring to the universe the
    blessed wonders of final releases. Mike's is one of them.
    I did hear from a guy who knows a guy that a v2 final release might be cut
    with the public GA launch of cf.com. But perhaps I hear what I want to
    hear :)
  • Dr Nic Williams at Jun 6, 2013 at 5:17 pm
    Unforkable isn't quite the right word. Anti-forking, perhaps.


    ​I think the release parts of a bosh release (.final_builds, releases) should be removed from the release repo; and converted into something like RubyGems. Then the repo is pure source and naturally forkable (and can maintain the parent relationship).



    ​Sorry to divert the thread :)

    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic
    On Thu, Jun 6, 2013 at 10:09 AM, Dr Nic Williams wrote:

    Can I propose that you don't fork cf-release; rather have a separate release for the jobs you customised? Then you merge them during deploy time as a composite release. Just a theory. Haven't don't it personally. But I'm very aware of the unforkable nature of bosh releases.
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic
    On Thu, Jun 6, 2013 at 10:06 AM, Mike Youngstrom wrote:
    Actually, after thinking about it. For our use case it would be best for
    us if we could just get a tag in the cf-release repo. Since we do our own
    final releases that include our custom jobs, a tag only would actually be
    perfect. It would simplifies our cf-release merges to not have to deal
    with "final" conflicts.
    Perhaps if tags only are provided in the main cf-release repo then it would
    still be simple for a group of public users like Dr. Nic to fork cf-release
    and provide their own final releases based off the cf-release tags?
    Mike
    On Thu, Jun 6, 2013 at 10:41 AM, Dr Nic Williams wrote:
    +1

    I have documented many good benefits for restoring to the universe the
    blessed wonders of final releases. Mike's is one of them.
    I did hear from a guy who knows a guy that a v2 final release might be cut
    with the public GA launch of cf.com. But perhaps I hear what I want to
    hear :)
  • Mike Youngstrom at Jun 6, 2013 at 5:29 pm
    I agree that long term de-coupling the releases from the code is the right
    solution.

    With regards to composite releases we currently override a couple of
    existing jobs and had trouble with that when we last looked at it several
    months ago. Do you know if there has there been progress in this area
    lately? I did a quick google search for some docs and more info on
    composite releases but didn't find much.

    Mike

    On Thu, Jun 6, 2013 at 11:16 AM, Dr Nic Williams wrote:

    Unforkable isn't quite the right word. Anti-forking, perhaps.

    I think the release parts of a bosh release (.final_builds, releases)
    should be removed from the release repo; and converted into something like
    RubyGems. Then the repo is pure source and naturally forkable (and can
    maintain the parent relationship).

    Sorry to divert the thread :)
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic

    On Thu, Jun 6, 2013 at 10:09 AM, Dr Nic Williams wrote:

    Can I propose that you don't fork cf-release; rather have a separate
    release for the jobs you customised? Then you merge them during deploy time
    as a composite release. Just a theory. Haven't don't it personally. But I'm
    very aware of the unforkable nature of bosh releases.
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic

    On Thu, Jun 6, 2013 at 10:06 AM, Mike Youngstrom wrote:

    Actually, after thinking about it. For our use case it would be best
    for us if we could just get a tag in the cf-release repo. Since we do our
    own final releases that include our custom jobs, a tag only would actually
    be perfect. It would simplifies our cf-release merges to not have to deal
    with "final" conflicts.

    Perhaps if tags only are provided in the main cf-release repo then it
    would still be simple for a group of public users like Dr. Nic to fork
    cf-release and provide their own final releases based off the cf-release
    tags?

    Mike


    On Thu, Jun 6, 2013 at 10:41 AM, Dr Nic Williams <
    drnicwilliams@gmail.com> wrote:
    +1

    I have documented many good benefits for restoring to the universe the
    blessed wonders of final releases. Mike's is one of them.
    I did hear from a guy who knows a guy that a v2 final release might be
    cut with the public GA launch of cf.com. But perhaps I hear what I
    want to hear :)
  • Dr Nic Williams at Jun 6, 2013 at 6:21 pm
    Ruben said he had composite releases working. Perhaps start a thread on that?
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic
    On Thu, Jun 6, 2013 at 10:29 AM, Mike Youngstrom wrote:

    I agree that long term de-coupling the releases from the code is the right
    solution.
    With regards to composite releases we currently override a couple of
    existing jobs and had trouble with that when we last looked at it several
    months ago. Do you know if there has there been progress in this area
    lately? I did a quick google search for some docs and more info on
    composite releases but didn't find much.
    Mike
    On Thu, Jun 6, 2013 at 11:16 AM, Dr Nic Williams wrote:
    Unforkable isn't quite the right word. Anti-forking, perhaps.

    I think the release parts of a bosh release (.final_builds, releases)
    should be removed from the release repo; and converted into something like
    RubyGems. Then the repo is pure source and naturally forkable (and can
    maintain the parent relationship).

    Sorry to divert the thread :)
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic

    On Thu, Jun 6, 2013 at 10:09 AM, Dr Nic Williams wrote:

    Can I propose that you don't fork cf-release; rather have a separate
    release for the jobs you customised? Then you merge them during deploy time
    as a composite release. Just a theory. Haven't don't it personally. But I'm
    very aware of the unforkable nature of bosh releases.
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic

    On Thu, Jun 6, 2013 at 10:06 AM, Mike Youngstrom wrote:

    Actually, after thinking about it. For our use case it would be best
    for us if we could just get a tag in the cf-release repo. Since we do our
    own final releases that include our custom jobs, a tag only would actually
    be perfect. It would simplifies our cf-release merges to not have to deal
    with "final" conflicts.

    Perhaps if tags only are provided in the main cf-release repo then it
    would still be simple for a group of public users like Dr. Nic to fork
    cf-release and provide their own final releases based off the cf-release
    tags?

    Mike


    On Thu, Jun 6, 2013 at 10:41 AM, Dr Nic Williams <
    drnicwilliams@gmail.com> wrote:
    +1

    I have documented many good benefits for restoring to the universe the
    blessed wonders of final releases. Mike's is one of them.
    I did hear from a guy who knows a guy that a v2 final release might be
    cut with the public GA launch of cf.com. But perhaps I hear what I
    want to hear :)
  • Gabrielle Sweda at Jun 14, 2013 at 9:55 pm
    The bosh and backend (cf-release) teams both have final releases in their
    near term plans.
    On Thursday, June 6, 2013, Dr Nic Williams wrote:

    Ruben said he had composite releases working. Perhaps start a thread on
    that?
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic


    On Thu, Jun 6, 2013 at 10:29 AM, Mike Youngstrom ({}, 'cvml', 'youngm@gmail.com');>
    wrote:
    I agree that long term de-coupling the releases from the code is the
    right solution.

    With regards to composite releases we currently override a couple of
    existing jobs and had trouble with that when we last looked at it several
    months ago. Do you know if there has there been progress in this area
    lately? I did a quick google search for some docs and more info on
    composite releases but didn't find much.

    Mike


    On Thu, Jun 6, 2013 at 11:16 AM, Dr Nic Williams ({}, 'cvml', 'drnicwilliams@gmail.com');>
    wrote:
    Unforkable isn't quite the right word. Anti-forking, perhaps.

    I think the release parts of a bosh release (.final_builds, releases)
    should be removed from the release repo; and converted into something like
    RubyGems. Then the repo is pure source and naturally forkable (and can
    maintain the parent relationship).

    Sorry to divert the thread :)
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic


    On Thu, Jun 6, 2013 at 10:09 AM, Dr Nic Williams <
    drnicwilliams@gmail.com <javascript:_e({}, 'cvml',
    'drnicwilliams@gmail.com');>> wrote:
    Can I propose that you don't fork cf-release; rather have a separate
    release for the jobs you customised? Then you merge them during deploy time
    as a composite release. Just a theory. Haven't don't it personally. But I'm
    very aware of the unforkable nature of bosh releases.
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic


    On Thu, Jun 6, 2013 at 10:06 AM, Mike Youngstrom ({}, 'cvml', 'youngm@gmail.com');>
    wrote:
    Actually, after thinking about it. For our use case it would be best
    for us if we could just get a tag in the cf-release repo. Since we do our
    own final releases that include our custom jobs, a tag only would actually
    be perfect. It would simplifies our cf-release merges to not have to deal
    with "final" conflicts.

    Perhaps if tags only are provided in the main cf-release repo then it
    would still be simple for a group of public users like Dr. Nic to fork
    cf-release and provide their own final releases based off the cf-release
    tags?

    Mike


    On Thu, Jun 6, 2013 at 10:41 AM, Dr Nic Williams <
    drnicwilliams@gmail.com <javascript:_e({}, 'cvml',
    'drnicwilliams@gmail.com');>> wrote:
    +1

    I have documented many good benefits for restoring to the universe
    the blessed wonders of final releases. Mike's is one of them.
    I did hear from a guy who knows a guy that a v2 final release might
    be cut with the public GA launch of cf.com. But perhaps I hear what
    I want to hear :)
  • Dr Nic Williams at Jun 14, 2013 at 10:01 pm
    Hurray for the Return of Final Releases coming soon! Lest we forget.

    Nic

    On Fri, Jun 14, 2013 at 2:55 PM, Gabrielle Sweda wrote:

    The bosh and backend (cf-release) teams both have final releases in their
    near term plans.
    On Thursday, June 6, 2013, Dr Nic Williams wrote:

    Ruben said he had composite releases working. Perhaps start a thread on
    that?
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic

    On Thu, Jun 6, 2013 at 10:29 AM, Mike Youngstrom wrote:

    I agree that long term de-coupling the releases from the code is the
    right solution.

    With regards to composite releases we currently override a couple of
    existing jobs and had trouble with that when we last looked at it several
    months ago. Do you know if there has there been progress in this area
    lately? I did a quick google search for some docs and more info on
    composite releases but didn't find much.

    Mike


    On Thu, Jun 6, 2013 at 11:16 AM, Dr Nic Williams <
    drnicwilliams@gmail.com> wrote:
    Unforkable isn't quite the right word. Anti-forking, perhaps.

    I think the release parts of a bosh release (.final_builds, releases)
    should be removed from the release repo; and converted into something like
    RubyGems. Then the repo is pure source and naturally forkable (and can
    maintain the parent relationship).

    Sorry to divert the thread :)
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic


    On Thu, Jun 6, 2013 at 10:09 AM, Dr Nic Williams <
    drnicwilliams@gmail.com> wrote:
    Can I propose that you don't fork cf-release; rather have a separate
    release for the jobs you customised? Then you merge them during deploy time
    as a composite release. Just a theory. Haven't don't it personally. But I'm
    very aware of the unforkable nature of bosh releases.
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic

    On Thu, Jun 6, 2013 at 10:06 AM, Mike Youngstrom wrote:

    Actually, after thinking about it. For our use case it would be best
    for us if we could just get a tag in the cf-release repo. Since we do our
    own final releases that include our custom jobs, a tag only would actually
    be perfect. It would simplifies our cf-release merges to not have to deal
    with "final" conflicts.

    Perhaps if tags only are provided in the main cf-release repo then it
    would still be simple for a group of public users like Dr. Nic to fork
    cf-release and provide their own final releases based off the cf-release
    tags?

    Mike


    On Thu, Jun 6, 2013 at 10:41 AM, Dr Nic Williams <
    drnicwilliams@gmail.com> wrote:
    +1

    I have documented many good benefits for restoring to the universe
    the blessed wonders of final releases. Mike's is one of them.
    I did hear from a guy who knows a guy that a v2 final release might
    be cut with the public GA launch of cf.com. But perhaps I hear what
    I want to hear :)

    --
    Dr Nic Williams
    Stark & Wayne LLC - consultancy for Cloud Foundry users
    http://drnicwilliams.com
    http://starkandwayne.com
    cell +1 (415) 860-2185
    twitter @drnic
  • Ruben Koster at Jun 19, 2013 at 3:32 pm
    Yes indeed composite releases are working. I'm using it for combining
    cf-release with
    with https://github.com/cloudfoundry-community/cf-services-contrib-release.
    Found some inspiration
    here: https://github.com/cloudfoundry/vcap-services-sample-release.
    But it basically boils down to specifying a "release:" for each job and
    change release: to releases:.


    On Thursday, June 6, 2013 8:21:46 PM UTC+2, Dr Nic Williams wrote:

    Ruben said he had composite releases working. Perhaps start a thread on
    that?
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic


    On Thu, Jun 6, 2013 at 10:29 AM, Mike Youngstrom <you...@gmail.com<javascript:>
    wrote:
    I agree that long term de-coupling the releases from the code is the
    right solution.

    With regards to composite releases we currently override a couple of
    existing jobs and had trouble with that when we last looked at it several
    months ago. Do you know if there has there been progress in this area
    lately? I did a quick google search for some docs and more info on
    composite releases but didn't find much.

    Mike


    On Thu, Jun 6, 2013 at 11:16 AM, Dr Nic Williams <drnicw...@gmail.com<javascript:>
    wrote:
    Unforkable isn't quite the right word. Anti-forking, perhaps.

    I think the release parts of a bosh release (.final_builds, releases)
    should be removed from the release repo; and converted into something like
    RubyGems. Then the repo is pure source and naturally forkable (and can
    maintain the parent relationship).

    Sorry to divert the thread :)
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic


    On Thu, Jun 6, 2013 at 10:09 AM, Dr Nic Williams <drnicw...@gmail.com<javascript:>
    wrote:
    Can I propose that you don't fork cf-release; rather have a separate
    release for the jobs you customised? Then you merge them during deploy time
    as a composite release. Just a theory. Haven't don't it personally. But I'm
    very aware of the unforkable nature of bosh releases.
    --
    Dr Nic Williams
    Stark & Wayne LLC - the consultancy for Cloud Foundry
    http://starkandwayne.com
    +1 415 860 2185
    twitter: drnic


    On Thu, Jun 6, 2013 at 10:06 AM, Mike Youngstrom <you...@gmail.com<javascript:>
    wrote:
    Actually, after thinking about it. For our use case it would be best
    for us if we could just get a tag in the cf-release repo. Since we do our
    own final releases that include our custom jobs, a tag only would actually
    be perfect. It would simplifies our cf-release merges to not have to deal
    with "final" conflicts.

    Perhaps if tags only are provided in the main cf-release repo then it
    would still be simple for a group of public users like Dr. Nic to fork
    cf-release and provide their own final releases based off the cf-release
    tags?

    Mike


    On Thu, Jun 6, 2013 at 10:41 AM, Dr Nic Williams <drnicw...@gmail.com<javascript:>
    wrote:
    +1

    I have documented many good benefits for restoring to the universe
    the blessed wonders of final releases. Mike's is one of them.
    I did hear from a guy who knows a guy that a v2 final release might
    be cut with the public GA launch of cf.com. But perhaps I hear what
    I want to hear :)
    --

    ------------------------------

    Have an innovative day

    *Innovation Factory *De Lairessestraat 180* *1075 HM Amsterdam* *+31
    20 7787008 www.innovationfactory.eu

    *
    Disclaimer*
    *The information transmitted is intended only for the person or entity to
    which it is addressed and may contain confidential and/or privileged
    material. Any use of, or taking of any action in reliance upon, this
    information by persons or entities other than the intended recipient is
    prohibited. If you received this in error, please contact the sender and
    delete the material from any computer. Innovation Factory does not accept
    liability for any errors, viruses or omissions in the contents of this
    message, which may arise as a result of e-mail transmission. No employee or
    agent is authorized to conclude any binding agreement on behalf of
    Innovation Factory with another party by email.*

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupbosh-users @
postedJun 6, '13 at 4:37p
activeJun 19, '13 at 3:32p
posts10
users5

People

Translate

site design / logo © 2021 Grokbase