proposal: build identifier after modifiers

[busla]

Great package, thanks for sharing 🙏🏼

I want to propose adding a build-identifier option that, if used, would be appended to a modifier. The identifier on previous versions would be ignored when determining next version, and would not affect the current version rolling logic.

This would also comply with semver conventions.

From semver:

Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3—-117B344092BD.

Example scenario

• Calver format: yy.mm.dd.patch
• Version on production: 22.9.10.0
• git short sha: abcd123

A developer is working on the feature deployment branch fixing-stuff and determined version for the first feature deployment is 22.9.10.1-dev.0 accessible at https://fixing-stuff-abcd123.dev.company.com. There are several services that participate in the deployment, e.g. sentry, spinnaker, et.c.

A build identifier that would become part of of the deployment chain would simplify targeting regressions or broken deployments.

Example version using a build identifier: 22.9.10.1-dev.0+fixing-stuff-abcd123.

This would allow developers and QA to quickly target where problems were solved (or occurred) during the development phase since it has a human annotation to it 😄

I am up for creating a PR if this makes sense, otherwise I will concat the build identifer to the calver version.

[muratgozel]

Hey 👋, thanks for pointing this out. I think this is completely valid and under the scope of this library. Let's clarify a few things before making any effort. I remember there are auto-generated build identifiers and there could be user-specified build identifiers as you suggested. The library should cover both cases if you ask me. (Maybe by placing a config param to the inc method?) I'm open to ideas and would happily accept a PR for this. My only concern for this library is to keep the codebase dependency-free and clean, easy to understand. Have you considered how to implement such logic?

[busla]

Hey, sounds great 🙌🏼

Right, so this is probably a hybrid of some sort, between pre-release denotation and build-identifiers. I guess both could be implemented but perhaps start with build-ids.

I totally agree with keeping the the dep-free policy 🤌

I have just scrolled through the code briefly but as a first iteration the string could be passed as a config param, like you suggest.

In the meantime, I created this wrapper 😄

https://github.com/busla/calver-ci

[muratgozel]

Looking good!

Here is how it could work: An identifier property could be specified under options argument. If I set it to true, library generates the identifier. if i set it to a string, library directly chose that string as identifier by applying some validation like [a-z0-9A-Z_\-].

calver.inc(format, '2021.1.1.0', 'minor', { identifier: true })
// or
calver.inc(format, '2021.1.1.0', 'minor', { identifier: 'my-identifier' })

What do you think?

[busla]

That would fit the requirements. I guess the identifier would mostly be used as a passthrough from the build services but I'm sure that there are scenarios where you just want it to be generated.

Perhaps instead of boolean, a configuration object could be passed so the user can compose the identifer using known properties within the enviroment (e.g. git). That would also allow for other configs, like separator.

Example:

const options = {
  separator: '-',
  attributes: [
    {
      commitSha: {
        length: 7,
      },
    },
    {
      commitBranch: {
        maxLength: 10,
      },
    },
    {
      commitAuthor: {
        maxLength: 10,
      },
    },
    {
      random: {
        maxLength: 15,
      },
    },
  ],
};

[busla]

a simpler approach would be to offer templates for common providers, e.g. Github, Gitlab, since we have access to loads env variables already in the pipelines.

[muratgozel]

And those templates could be like { identifier: "[branch][hash:16]" } because some of us are already familiar with this approach:
https://github.com/webpack/loader-utils#interpolatename

All of the above makes sense! I think we can start with { identifier: "my-identifier" } (which I think is what you need primarily) and then expand it later to cover object type options. I would like to leave this issue open for future opinions. Send a PR please if you have time.

[busla]

ahh!

even better to use something conventional 🙌

will create a PR soon.