kekavc24 / magical_version_bump Goto Github PK

Description

Partial support for JSON was added after #28 was closed. However, key differences and similarities exist in both, with each having its strengths. It would be great to extend and support that

Requirements

• #45

  {
      "key" : [ "normal", ["nested"] ]
  }

• #44

 {
      "key" : [  "normal value", {"nested" : "map"}, "another value" ]
  }

In Yaml, a nested list would need to be linked to another key. So any list would technically be incorporated to the nearest key.

key:
    - normal value
    
     # a nested map in list in yaml
    - nested: map
      another key: value

    - another value
    
    # a nested list linked to a key
    - nested-list:
        - nested value
        - another value

As I made changes that will reflect once #13 is merged, I was at a crossroad before settling on the default behavior. Currently (starting from v0.5.0 ), when you do:

mag modify --set-version=1.1.1 --set-prelease=foo --set-build=bar --bump --major

# Or

mag modify --preset --set-version=1.1.1 --set-prelease=foo --set-build=bar --bump --major

Results in the same behavior. This because --set-version defaults --preset to always true. Thus, version , prerelease and build if passed will be preset before version is bumped.

However, doing:

mag modify --set-prelease=foo --set-build=bar --bump --major

Only sets the prerelease and build after the current version 's major version in yaml has been bumped.

The crossroad then was:

• preset should preset the value before bumping. Part of the default behavior.
• set-version should only preset the version if preset is not specified. Thus:

mag modify --set-version=1.1.1 --set-prelease=foo --set-build=bar --bump --major

Only presets version and adds prelease and build metadata after the major version has been bumped up.

Description

Consider the version 2.3.4+myCustomBuild. If you were to do:

# -b is just shorthand for bump
mag modify -b major

The bumped version would be 3.0.0 and the build metadata would be removed since it doesn’t check.

Expected Behavior

The tool should keep the custom build metadata. Optionally, should warn if user is attempting to bump the build number of custom build metadata.

Description

This implementation is fairly straightforward. Currently, tool does great as the file is read as a string.

The issue comes in when saving it back to the json file. The version is formatted by the yamEdit package I use to edit nodes.

Description

In addition to supporting semVer, it would be great to support calVer ?

Requirements

• Add calVer support to modify command

Additional Context
Although semVer is great and recommended by Flutter/Dart team, it would be great to support calVer too. I noticed a vocal minority saying they love calVer too.

Plus it's awesome to include everyone 😃

Currently, tool doesn't allow one to add maps within lists. Both JSON and latest version of YAML allow this.