chore: bump version for 0.2.0-rc2 release; bump keri to 1.2.4

[kentbull]

No description provided.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.78%. Comparing base (ab20766) to head (40403b8).
Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #356      +/-   ##
==========================================
+ Coverage   93.71%   93.78%   +0.06%     
==========================================
  Files          37       37              
  Lines        8293     8415     +122     
==========================================
+ Hits         7772     7892     +120     
- Misses        521      523       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[2byrds]

LGTM

[m00sey]

What's the release strategy here?

Is main to become 0.2.0-rc2?

Typically in keripy the change would be merged to 0.2.0-rc1, that branch becomes 0.2.0-rc2 and possibly the change pushed to main as well, at least that was my understanding @pfeairheller

@kentbull asked me to do a release, is this from main to become 0.2.0-rc2?

[kentbull]

whoops, I made a mistake here. I should have targeted the 0.2.0-rc1 branch. I forgot about the release process.

I'll make a 0.2.0-rc2 branch and then keep this in mind for future release candidate changes.

[iFergal]

There should just be a 0.2.0 or v0.2.0 release branch with all the release candidates and final release. Main could go to 0.3.0-dev0 when someone needs a release of anything newer

[m00sey]

Well, the change is in main now because it was merged?

At this point you may as well delete the 0.2.0-rc1, make 0.2.0-rc2 from main?

Given the minimal changes I don't see this hurting, but it would be nice to see PRs merged using the same strategy across repos.

[kentbull]

Yes, I will make 0.2.0-rc2 from main and target any further 0.2.0 RC PRs to that branch.

[iFergal]

OK with me but the branch should be called v0.2.0. The tags have rc in them, and all sit on the branch. This aligns with keripy too. It shouldn't be a new branch per rc

[m00sey]

We actually rename the branch in keripy and add a tag. Your suggestion might be an improvement @iFergal

[m00sey]

To clarify, the tags remain a reference point of when the tag was made, but the branch always has the latest name (for that release) - and its name reflects the latest "version".

[iFergal]

Ah, ok, and they have the final version name now in keripy since those are fully released. My mistake.

I've only ever seen release/x.y.z (I like the prefix too) or x.y.z branches before cut, and then yes, creating the tags on that branch as a reference point on the branch. To me that is less confusing that branch names updating.