Change of versioning agreement#6195
Conversation
|
Great thanks @pmuens for review, very good suggestions. I've addressed all points |
pmuens
left a comment
pmuens
left a comment
There was a problem hiding this comment.
Any update on this one? Looks like this is in a pretty good shape and can be merged quite soon.
|
I guess we need some feedback from product team, and confirmation that's ok to go (?) I didn't receive any on Slack, I expect that today we will discuss that in a meeting. |
|
Sounds good. Let's discuss it in todays meeting 👍 |
I was told this would be discussed tomorrow during product planning call |
I see. In that case, let's wait for the outcome of that meeting... |
| 4. Why is CLI output a breaking change? | ||
| 1. Why is CLI output a breaking change? | ||
|
|
||
| Right now we don't provide an option to output a well formated datastructure for a CLI command. Once we have such an option the default CLI output will not be part of the breaking changes list, but rather the datastructure. Also to note here if we add to that datastructure it will not be a breaking change. If we remove or change something from that datastructure it is a breaking change. |
There was a problem hiding this comment.
After reading this again I think it doesn't really make sense.
Above we state that changing CLI stdout is not a breaking change. However here we say that it would be a breaking change until we introduce a formatted datastructure.
Isn't this a contradiction? Or am I missing something? 🤔
There was a problem hiding this comment.
This was left intact, but I understand it as:
- Why is change of CLI output a breaking change?
- It's because we do not provide a programmatically consumable alternative. Once we will provide it, we will categorize changes to human readable CLI output as non-breaking
Still I see it as controversial, as anyway I think we improve wording and fix typos of CLI output now, and do not announce such changes as breaking. So technically we do not perfectly comply to this
There was a problem hiding this comment.
Yes, true. I just stumbled upon this while reading it. It's very vague, up for interpretation and controversial.
Let's keep it for now (as nobody complained so far) and update it later on.
|
Is this versioning change allow us to introduce some breaking changes during |
|
@exoego We definitely want to workout a strategy where we can introduce a breaking changes, so we can progress with improvements for the framework. This PR is on hold, as at this point we're investigating a possibility on following semver with that, as that will definitely be more standard way and I believe it's what most of the framework users will expect. |
|
Any updates on this PR? Can we merge it soon and ship it in v1.48.0? |
I don't think there was an agreement on that way of handling breaking changes. My observation is that we aim to follow semver, but to finally settle on that and push it into action, first we need to clarify how Framework and Components should coexist/integrate I believe merging #6350 is a first step for that roadmap to be clarified. Having that, in 1-2 months we should decide on something concrete I believe. In a meantime I plan to specify some clearly breaking changes which will be about significant improvements, that should also put better light on why witholding major releases (in semver spirit) puts on ourselves handcuffs. We should be able to produce breaking changes every few months (at least after this long stagnation period I imagine major improvements even every 2 months) Anyway I think we need a bit more time for some things to settle. I hope we'll just close this PR, but until we have final green light on semver I'd keep it open |
|
Makes sense. Thanks for the update @medikoo 👍 |
|
Look at the way
|
|
@BryanCrotaz we're looking forward to follow semver respectfully. When we will reach the pace of having at least few major releases per year, then I believe we will also incorporate deprecation model you're outlining, btw that's a really great suggestion. Thanks for posting this. |
Look at the reputational damage done to Angular with the release of v.2. Ember never suffered this due to the above release model. I'd recommend looking at this before your first major release. |
|
I'm closing this, as so far agreement is that we want to stick to semver. If anything changes we may reconsider this PR |
5 participants
Update to VERSIONING document, which outlines a new versioning rules which will allow us to introduce a breaking changes with MINOR releases
Is this ready for review?: NO
Is it a breaking change?: NO