New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rebrand (post-RC, pre-stable) #861

Closed
aanand opened this Issue Jan 20, 2015 · 7 comments

Comments

Projects
None yet
5 participants
@aanand
Contributor

aanand commented Jan 20, 2015

These are the steps to take before the stable release of Compose 1.1.0.

  • Rename the GitHub repo
  • Update install docs with new binary URL (#1021)
  • Update completion docs with new script URL (#1021)
  • Add "previously known as Fig" note to README.md (#1022)
  • Update Bash completion script
  • Create a fig-stable branch from the 1.0.0 tag
  • Create the #docker-compose IRC channel

After releasing on PyPi:

  • Add a deprecation notice to the PyPi page for fig

After the docs have been deployed:

@aanand aanand added this to the 1.1.0 milestone Jan 20, 2015

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jan 20, 2015

Member

Just to inform; upon release of compose, will there also be a fig alias to ease the migration? Preparing myself to make my colleagues get used to using another command (and ... tbh, fig is still nice and short)

Also, will compose still look for fig.yml files, or do they have to be renamed?

Member

thaJeztah commented Jan 20, 2015

Just to inform; upon release of compose, will there also be a fig alias to ease the migration? Preparing myself to make my colleagues get used to using another command (and ... tbh, fig is still nice and short)

Also, will compose still look for fig.yml files, or do they have to be renamed?

@dnephin

This comment has been minimized.

Show comment
Hide comment
@dnephin

dnephin Jan 21, 2015

Contributor

(Linking in #864 to answer @thaJeztah question for anyone interested)

Should we close this 1.1.0 milestone and create a new 1.1.0-rc2 milestone?

Contributor

dnephin commented Jan 21, 2015

(Linking in #864 to answer @thaJeztah question for anyone interested)

Should we close this 1.1.0 milestone and create a new 1.1.0-rc2 milestone?

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Jan 23, 2015

Contributor

I don't think we need to release another RC unless there are critical bugs.

Contributor

aanand commented Jan 23, 2015

I don't think we need to release another RC unless there are critical bugs.

@bfirsh

This comment has been minimized.

Show comment
Hide comment
@bfirsh

bfirsh Jan 27, 2015

Contributor

I think we should release a second RC. An RC should be complete bar critical bugs. I'm not sure it needs a separate milestone though – ideally the 1.1.0 and 1.1.0-rc2 milestones should be the same. ;)

FYI – Engine and Machine are releasing second RCs on Tuesday or Wednesday.

Contributor

bfirsh commented Jan 27, 2015

I think we should release a second RC. An RC should be complete bar critical bugs. I'm not sure it needs a separate milestone though – ideally the 1.1.0 and 1.1.0-rc2 milestones should be the same. ;)

FYI – Engine and Machine are releasing second RCs on Tuesday or Wednesday.

@albers

This comment has been minimized.

Show comment
Hide comment
@albers

albers Jan 27, 2015

Member

Will bash completion be included in the release?
Currently bash completion is only referenced from the docs with the link pointing to the current development state in the repo. Thus, Compose and its completion are bound to run out of sync.
(This also raises the question whether putting completion on code freeze makes sense at all.)

Member

albers commented Jan 27, 2015

Will bash completion be included in the release?
Currently bash completion is only referenced from the docs with the link pointing to the current development state in the repo. Thus, Compose and its completion are bound to run out of sync.
(This also raises the question whether putting completion on code freeze makes sense at all.)

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Feb 5, 2015

Contributor

The docs point to the release tag (currently 1.1.0-rc2), so there's no risk of version drift there. I've added a checklist item to update it when we release.

Contributor

aanand commented Feb 5, 2015

The docs point to the release tag (currently 1.1.0-rc2), so there's no risk of version drift there. I've added a checklist item to update it when we release.

@albers

This comment has been minimized.

Show comment
Hide comment
@albers

albers Feb 6, 2015

Member

Perfect! Thanks @aanand.

Member

albers commented Feb 6, 2015

Perfect! Thanks @aanand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment