Release automation of kendo-themes

[joneff]

For a while now we've been using lerna 4 and things are not ideal, to say the least... We have three, possibly more, cases. I will explore them all:

Stable (official / latest) version

No-brainer: from the latest master branch, release the next version based on conventional commits.

As simple as this sound, we sometimes ended up with empty or incomplete changelogs and there were two reasons for that:

• to quote "Lerna version ... identifies packages that have been updated since the previous tagged release" (emphasis mine). There is no additional check for release bump type. Meaning, if we tag a dev release and we then graduate it, the changelog will be empty!
• github checkout action does shallow clone by default (fetch-depth: 1) and there are no commits to analyze. There is one exception and that was when we trigger publish without merging prior to master. In that case, when publish action fetches dev branch, it acquires some additional commits to analyze.

To sum up: in order to have adequate latest release and changelog, we need to fetch the entire history of the repo and not to have tagged non-latest releases.

Pre-releases (dev) of current version

Pre-releases work in exactly the same way as latest releases -- lerna will perform the exact sameworkflow.

Which brings us to an excellent catch 22: we must not tag dev releases in order to get complete change log; however, if we don't tag dev releases, we can only get -dev.0 version.

If we use --canary, then it's a whole new bag of snakes. To quote:

When run with this flag, lerna publish publishes packages in a more granular way (per commit). Before publishing to npm, it creates the new version tag by taking the current version, bumping it to the next minor version, adding the provided meta suffix (defaults to alpha) and appending the current git sha (ex: 1.0.0 becomes 1.1.0-alpha.0+81e3b443).

That means it counts the commits between releases, which may present interesting increments: -1, -2, -4, -7.

Publishing with canary also does not publish packages that have no need to be published, which interferes with our idea that all packages are released together.

Finally, canary builds to not take into consideration bump in major version, unlike the other pre- bumps in lerna.

To sum up: in order to have adequate pre-release, we need to not tag dev branches and instead use another method for determining versions.

Next version

A next version, to us, is yet unreleased major version. That puts it somewhere in the middle... We probably need to use similar nudges and suggestions for lerna in order to have correct releases.

---

My suggestion is, for the themes, at leas:

• split stages of release to separate steps a-la semantic release: analyze commits, build changelogs, publish
• for pre-release versions (both next and dev) nudge lerna in the right direction during the analysis phase

/cc @tsvetomir @eeasss @ivanchev @telerik/web-components-lt

[tsvetomir]

Looks like "canary" releases are the closest we could get with stock Lerna. We could live with the version number uncertainty, although it's not ideal.

A combination of --canary and --force-publish is suggested to publish all packages, see lerna/lerna#2060.
Would that work for us?

[joneff]

--canary --force-publish will indeed publish all packages with the same version, but will use the regular canary version resolution: if the previous canary version was [email protected] and we've made 20 new commits (regardless of type), the new canary version will be [email protected].

As far as next releases are concerned, assuming we didn't already have a pre bump, and then we rebase from dev and the previous version was [email protected], the new version would be anywhere in the [email protected] (full parity between commits) to [email protected] (no parity between commits).

When new latest version is released (assuming 4.42.0) and v5-dev is rebased against develop, the smallest version possible, I think, would be the number of commits that v5-dev is ahead of develop, which is weird, at best... i.e. [email protected] (assuming 21 unique commits ahead of develop). I haven't actually tested that scenario, so I cannot confirm, yet.

IMO, --canary is not a good fit for us and we should go to lerna nudging.

FWIW, we already do version hinting and lerna nudging: we did in the themes (see scripts/semver-dev-inc.js) and we do it with @telerik/semantic-prerelease for most other repos.

[Juveniel]

I think we can mark this as resolved with: 237a5fd

As future steps for improvements we can slowly start replacing soon-to-be legacy Lerna modules( lerna/bootstrap ) and migrating towards using npm workspaces instead.