search

confluentinc / confluent-cli

Confluent Platform CLI
Other
60 stars 38 forks source link

PLAT-267: checkout post branch instead of tag, to ensure existence an… #113

Closed ybyzek closed 5 years ago

ybyzek commented 5 years ago

…d up-to-date demo code

ewencp commented 5 years ago

In general release tags should be preferred as they are the things actually guaranteed to exist, post branches are a kind of weird setup just to enable docs updates.

It looks like cp-demo is now in the PLATFORM release group so should be getting tagged along with releases, so it seems like the tag should always exist anyway (and if not, seems like we should just fix that).

Perhaps the reasoning stated is not accurate? If the goal is to be able to update demo after release, that's different and would be done through -post, though I would argue that if we need to do that we should a) make sure it's in a better state before release and b) do those updates through bugfix releases.

ybyzek commented 5 years ago

@ewencp you are right, the goal is absolutely to be able to update the demo after release. Demo creation/update is not tied to release GA, and it is definitely part of the regular workflow that there are edits after GA.

a) make sure it's in a better state before release

New demo additions that take advantage of new features often happen after GA

b) do those updates through bugfix releases

Can you please elaborate on what you mean by bugfix release with relation to the demos?

ewencp commented 5 years ago

for (b), I meant that while development of updates to demos might happen against latest .x branch updates, public visibility and publication of those updates to demos could still be gated through an actual bugfix release. e.g., iterate on demos after a.b.0 release by working/building/testing against a.b.x branch, but they are made visible/public by kicking off an actual a.b.1 (or whatever bugfix version) release.

just pointing out that there are various ways to tie these things together, whether pulling into rest of platform release process and potentially resulting in more frequent releases even only demos get updated; or decoupling, assuming separate layering, separate release schedules, separate versions, etc but potentially complicating coordination. no strong preferences here on my part, just trying to point out different options that are worth considering.

ybyzek commented 5 years ago

Closing due to 5.3 CLI strategy