-
Notifications
You must be signed in to change notification settings - Fork 21
Add stack
and stack_next
variables to assembler.yml
#1541
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
Conversation
Label error. Requires exactly 1 of: automation, breaking, bug, changelog:skip, chore, ci, dependencies, documentation, enhancement, feature, fix, redesign. Found: |
I am not loving This requirement might warrant on us explicitly having:
Content sources and environments. That way the release manager can bump @reakaleek @cotti wdyt? |
@colleenmcginnis what happens when the Is it an exact snapshot of |
My understanding is that 9.1 is branched off of main in most (all?) repos so it should be identical when it is first created. |
Personally, I like the suggestion from @colleenmcginnis. But TBH, I don't fully understand your concern @Mpdreamz |
I guess my main concern is that staging is either After feature freeze there would be no environment for With the edge environment always being |
@Mpdreamz can I close this now that we have |
Yeah! |
I'm working on updating the docs release checklist for Elastic Stack releases. In the current draft, I'm recommending that the docs release coordinator touches this file twice:
stack_next
to the version of the upcoming release. The idea is that we'll be publishing those docs to staging (right?) so we'll be able to catch any build errors (like any broken cross-repo links) ahead of the release date. Does this make sense?stack
to the new version and updatestack_next
tomain
(I don't think any Stack-versioned repos still usemaster
).Let me know what you think of this approach. I'm very open to suggestions.