[MGNLFE-39] Release Frontend Helpers 1.0.1 Created: 08/Apr/20  Updated: 25/May/20  Resolved: 29/Apr/20

Status: Closed
Project: Magnolia Frontend Helpers
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Neutral
Reporter: Simon Lutz Assignee: Robert Šiška
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MGNLFE-51 Release Frontend Helpers 1.0.2 Closed
Relates
dependency
depends upon MGNLFE-38 Code example in react-editor README i... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: SPA Editor
Sprint: 6.2.1 Ramp-up 22, HL & LD 1
Story Points: 3

 Description   

This ticket covers:

  • release of 1.0.1
  • investigation related to automatic changelog generation

Proposal: Release frontend-helpers systematically at every end of a sprint with FE tickets

  • fast release cycle is good there, release is fast too
  • start building a proper change log in each package README (part of the release process), include updates in ticket PRs
  • release systematically unless one change depends on a Magnolia change (in which case it might be better to wait before merging)


 Comments   
Comment by Robert Šiška [ 24/Apr/20 ]

mgeljic, czimmermann
According to semantic versioning rules, major version number should change when there are backwards-incompatible changes. Both angular-editor and react-editor have those, but template-annotations don't.

Therefore, next versions of angular-editor and react-editor should be 2.0.0 and next version of template-annotations should be 1.0.1.

That also means, that we have to keep separate versions in Jira for each package, as explained here: https://wiki.magnolia-cms.com/display/DEVINT/Release+process+for+NPM+packages

Comment by Christopher Zimmermann [ 24/Apr/20 ]

You are absolutely correct. However we discussed this and decided to break the rules on our very first update to the libraries as we 'get the house in order'. This has been part of the reason for the urgency in getting this 1.0.1 release out. After this we should follow semver.
This pains me, but I think its the best approach, and I dont think its so bad since its very quick and there probably has not been a huge uptake yet.

We could add something to the effect in the releasenotes/changelog: like - 

Please excuse the breaking changes in 1.0.1
Changes are significant but it's easy to migrate.
We will follow semver for future releases.

 

Comment by Mikaël Geljić [ 24/Apr/20 ]
  • Does the audit complain about this?
  • Can we list each incompatibility separately?

Then we can think of ways we could mitigate these (e.g. still support the content property and warn + flatten content if it's still passed the old way; just one of many options). A bit extra work, but this way we can keep freedom to evolve our libraries and components, while at the same time giving developers time to update. A V2.0.0 is equally surprising if there is no warning and the project stops compiling, even if semver says it's ok, we can be a bit nicer and guide developers through those future evolutions.

Generated at Mon Feb 12 05:43:38 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.