Closed fredemmott closed 2 years ago
xy0
would not be accurate if we switched to semver.
Why not create-release-branch-and-trigger-build
?
xy0 would not be accurate if we switched to semver.
Why not? Semver would just mean that y is often 0 and x increases more often, this would still be the right script - if and only if - .z is 0.
Why not create-release-branch-and-trigger-build?
Similar problem to the current name: it's potentially confusing/misleading as it does not create the release branch of the facebook/hhvm if existing-tag
is specified. It does create the release branches in the packaging and docker repos though
The problem of make-xy0-release
is that it does not explain which steps are included in this script. For example, does it include tagging and pushing to hhvm-staging
? Does it include bumping version.h
?
The name make-xy0-release
is at least vague to me. I still does not understand what it does unless reading its content.
Yeah, that's fair; I still feel this is an improvement over the status quo.
I think the real fix would be to - like build-on-aws - make the steps chooseable - but also make it interactive. No ambiguity about what's running, explicit yes/no on which step as you go, perhaps with --promote-nightly-to-release=YYYY.MM.DD
for the common case
If that path were taken, would also merge with the tag-and-push script - it would be just another step in this.
Similar problem to the current name: it's potentially confusing/misleading as it does not create the release branch of the facebook/hhvm if
existing-tag
is specified. It does create the release branches in the packaging and docker repos though
How about create-release-branches-and-trigger-build
? The plural form of branches implies this script may create branches in multiple repositories.
I still feel the name's misleading if it doesn't create the branch that seems most reasonable to call the release branch
Going to leave for now, and re-open with just the docs change.
The name describes the primary use case, but is confusing for other situations.
Keep a symlink for compatibility (both with scripts and documentation), and extend documentation while I'm here.