Resurrect auto releases

[CAMOBAP]

Idea:

• On mnconvert.jar, information about increment strategy must be passed, major, minor, or patch, some python scrip for this should be implemented
• On mnconvert-ruby we will use this strategy to update corresponding section in version

cc @ronaldtse

[ronaldtse]

@CAMOBAP mnconvert.jar already provides version information in command line.

[CAMOBAP]

@ronaldtse at this moment latest mnconvert.jar is v1.13.0, latest mnconvert-ruby is v2.0.0 (because we did breaking changes)

Let's say the next release of mnconvert.jar will be v1.14.0, or v1.13.1, how should we change our mnconvert-ruby version?

[ronaldtse]

You can use v2.X.Y.Z to the vX.Y.Z of mnconvert.jar.

[CAMOBAP]

This implicitly creates restrictions to mnconvert.jar:

• use only three components vX.Y.Z
• this will not help in case if we will need to release PATCH or MINOR updates on mnconvert-ruby. Let's say we will need to release a patch with v2.1.13.1, and next release of mnconvert.jar for v1.13.1 will lead to conflict

My approach will correctly handle all those cases and make releases of mnconvert.jar and mnconvert-ruby really independent.

A single downright of this approach that mnconvert.jar and mnconvert-ruby but if we decided to keep them separated ( in separate repos) that's fair enough that they may have different versions

[ronaldtse]

@CAMOBAP The previous approach was that mnconvert-ruby followed mnconvert.jar versioning with a patch version that makes a difference.

e.g. mnconvert.jar v1.2.3 is used in mnconvert gem in v1.2.3.0. Updates to mnconvert gems are represented as X in v1.2.3.X.

The recent breaking change broken this convention because the Metanorma gemspec did not restrict usage of versions related to mnconvert gem, without regard to mnconvert.jar.

I'm fine to have the versions independent, but the original intent of mnconvert gem is PURELY for including/representing mnconvert.jar.

If the gems have independent versions then perhaps they should not be named identically.

[CAMOBAP]

@ronaldtse I agree with every line which you are writing above.

And next time for such *-ruby wrappers I am sure that we should never use argument-based methods like run(arg0, arg1, arg2) but only keyword arguments run(arg0:, arg1:, arg2:)

I also really like the idea of synchronized versions.

But what should we do in this situation to synchronize versions back? I see only one option:

• a 'fake' major release of mnconvert.jar with version 2.0.1, and enable back automation release workflow

[ronaldtse]

@CAMOBAP we can also revoke the published version 2 gem if we want to sync.

[CAMOBAP]

@ronaldtse yes we can, and because we are probably a single user of this gem, I hope it will not affect anyone, metanorma-iso isn't released yet

There is no perfect choice at all, let me compare all approaches:

1. mnconvert gem must PURELY for representing mnconvert.jar

1. Restriction: no own releases of mnconvert-ruby
2. Restriction: any changes made in mnconvert-ruby will wait to be released after upstream mnconvert.jar release
3. Doing 'fake' releases of mnconvert.jar to release pending changes in mnconvert-ruby
4. It may be useful during troubleshooting if mnconvert-ruby version and mnconvert.jar version are the same
5. we should track breaking changes in mnconvert-ruby too, and if need do MAJOR release of mnconvert.jar

2. mnconvert gem and mnconvert.jar. have completely independent release strategies

1. we can release mnconvert-ruby anytime manually (via CI or by pushing tag)
2. mnconvert.jar release still can trigger mnconvert-ruby
3. we follow https://semver.org/
4. "an internal perfectionist "hate the fact that version may vary significantly
5. automate release workflow need to be updated

3. allow mnconvert gem to have its own releases but only for PATCH action (x.y.Z, only for Z)

1. Restriction: to mnconvert.jar to never use Z component
2. Restriction: no major releases of mnconvert-ruby
3. formally versions will not be the same
4. automate release workflow need to be updated, to support the case when mnconvert-ruby was released and jar version != gem version

Notes:

• If we really consider mnconvert, mnconvert-ruby as a monolith, the first scenario (with fake releases) should not be ok
• We use the third approach on release metanorma->packed-mn->{choco,snap,brew}. But there is an impossible case when packed-mn will introduce any breaking changes

@ronaldtse @Intelligent2013 how do you think about this?

I still thinking, and cannot select between any it right now...

[CAMOBAP]

@ronaldtse @Intelligent2013 please share your vision

[Intelligent2013]

@CAMOBAP the main application is mnconvert. mnconvert-ruby is just wrapper for mnconvert. In case of issue in business logic I need to know the version that installed in user environment, i.e. should be compliance between mnconvert and mnconvery-ruby versions to determine it. For instance, 1.5 vs. 1.5.0 or 1.5.1 is ok for me. So I think 3rd approach is preferrable.

[ronaldtse]

Agree with @Intelligent2013 , thank you @CAMOBAP !

[CAMOBAP]

Great! Action items:

• [x] enable automatic release management back
• [x] do v1.13.1 release of mnconvert-ruby
• [x] update dependency version restrictions in https://github.com/metanorma/metanorma-iso

[CAMOBAP]

https://github.com/metanorma/metanorma-iso/pull/563 - created

closing this one