BREAKING CHANGE(spec): Change volumeName to volumeRef

redhat-developer / opencompose

OpenCompose - A higher level abstraction for Kubernetes Resource

Apache License 2.0

64 stars 12 forks source link

BREAKING CHANGE(spec): Change volumeName to volumeRef #136

Closed surajssd closed 7 years ago

surajssd commented 7 years ago

Right now we refer a volume name from mounts section of containers with field called volumeName, change it to volumeRef.

This also introduces a convention of naming fields in OpenCompose spec. So any field that is referencing to some other field it should end with 'Ref'.

Breaks the way we refer the volume name.

Fixes #119

kadel commented 7 years ago

one question: What are we going to do with proposals? (docs/proposals/volumes-proposal.md) shouldn't this be updated also?

surajssd commented 7 years ago

@kadel I thought of keeping it just like that? Not sure what is the right thing to do!

Also maybe we can list of changes that happened over time to the original proposal. I think our docs should single point of truth!

kadel commented 7 years ago

My issue with keeping it as it is is that it might be a bit confusing if we have something that is not true anymore in proposals.

I see a couple of options that we can do:

add big warning to the beginning of the proposal saying that its original proposal and it might not be valid anymore (or we could create README.md in proposal dir)
keep it up to date (changelog in git history) (duplicate effort, we will have to keep reference-file.md and proposals up to date.)
add a changelog to file directly
reconsider if it makes sense to keep proposals in docs (proposals could be done directly as PR to reference-file.md)

concaf commented 7 years ago

@surajssd @kadel IMO, we should not change the proposal, but we should mention at the starting of every proposal that this was the original proposal and this might have totally changed. We should focus on keeping the docs updated, not the proposals. Proposals should serve a historical purpose, that what was the reasoning around adding this at the time of merging; it's not a proposal anymore when we are making fixes.

kadel commented 7 years ago

@containscafeine agreed. Does it make sense to have it in docs then? Maybe we should remove it from docs dir, I'm afraid that some users could use it as reference documentation.

Isn't history in PRs and issues enough? It sais a lot more about reasoning around adding it as it includes all the discussions, proposal files are just result of that discussion.

surajssd commented 7 years ago

@kadel @containscafeine i don't have opinions on this please tell me what should be done? Let's not bike shed so much on it and get this thing in? Unless there are any code related issues?

concaf commented 7 years ago

@kadel, ack, I agree on removing proposals altogether and just maintaining docs. @surajssd imo, let's merge this PR and we can remove proposal in a separate one.

kadel commented 7 years ago

opened https://github.com/redhat-developer/opencompose/issues/137