Partially automate release - release branch creation and version updates [DI-669]

[JackPGreen]

Partially automates the steps listed in the C++ Client Release Process documentation.

Specifically, steps:

• Create branch
• Update next version

By scripting and chaining the steps, the (manual) release work is reduced and consistency is improved.

Testing (in my fork):

• example execution
• branch created
• version update PR raised - (note, action is included in PR as I've since reset my forks' master, it's not actually in the PR)

Post-merge actions:

• update docs

Partially addresses: DI-669

[nishaatr]

Good from my side
if we keep using PR its fine but still would prefer direct push

[JackPGreen]

Good from my side if we keep using PR its fine but still would prefer direct push

I'll raise on the standup next week. It's probably a wider issue than the C++ client.

[nishaatr]

[JackPGreen]

Might've got carried away with find and replace...

35c32ca

[nishaatr]

forgot to mention about maintenance branch
here it says create z-branch
wondering if z-branch is actually used or how frequently! may be no need

[JackPGreen]

forgot to mention about maintenance branch here it says create z-branch wondering if z-branch is actually used or how frequently! may be no need

Good point. I've added the optional ability to supply a branch name in 22533ba

[JackPGreen]

forgot to mention about maintenance branch here it says create z-branch wondering if z-branch is actually used or how frequently! may be no need

Good point. I've added the optional ability to supply a branch name in 22533ba

Actually, I think this is wrong.

It doesn't say to create z-branch - it says to create a release branch from one of the branches (master, z etc).
Where the z branch is created is absent from the docs so is out of scope for now.
But It means the existing implementation was fine, so reverted.

9c8fb84

[ihsandemir]

forgot to mention about maintenance branch here it says create z-branch wondering if z-branch is actually used or how frequently! may be no need

Good point. I've added the optional ability to supply a branch name in 22533ba

Actually, I think this is wrong.

It doesn't say to create z-branch - it says to create a release branch from one of the branches (master, z etc). Where the z branch is created is absent from the docs so is out of scope for now. But It means the existing implementation was fine, so reverted.

9c8fb84

Having the 5.6.z auto created may be a good practice, since normally we should always backport the bug fixes as possible and when you want to do it, the branch would be ready. What is the practice at platform releases? We can use the same approach.

[JackPGreen]

forgot to mention about maintenance branch here it says create z-branch wondering if z-branch is actually used or how frequently! may be no need

Good point. I've added the optional ability to supply a branch name in 22533ba

Actually, I think this is wrong.
It doesn't say to create z-branch - it says to create a release branch from one of the branches (master, z etc). Where the z branch is created is absent from the docs so is out of scope for now. But It means the existing implementation was fine, so reverted.
9c8fb84

Having the 5.6.z auto created may be a good practice, since normally we should always backport the bug fixes as possible and when you want to do it, the branch would be ready. What is the practice at platform releases? We can use the same approach.

Probably one for @nishaatr to answer.

[nishaatr]

forgot to mention about maintenance branch here it says create z-branch wondering if z-branch is actually used or how frequently! may be no need

Good point. I've added the optional ability to supply a branch name in 22533ba

Actually, I think this is wrong.
It doesn't say to create z-branch - it says to create a release branch from one of the branches (master, z etc). Where the z branch is created is absent from the docs so is out of scope for now. But It means the existing implementation was fine, so reverted.
9c8fb84

Having the 5.6.z auto created may be a good practice, since normally we should always backport the bug fixes as possible and when you want to do it, the branch would be ready. What is the practice at platform releases? We can use the same approach.

Probably one for @nishaatr to answer.

In Platform z-branch is created for MAJOR/MINOR. It will also updates version in master (MAJOR/MINOR ) and z-branch (PATCH). This is all automatic based on the supplied release type

prefer its automated here. So if BRANCH_NAME ends with .z then don't create z-branch, otherwise create one
then update z-branch version to the next version (@ihsandemir is this correct?). For master we have this step

[JackPGreen]

forgot to mention about maintenance branch here it says create z-branch wondering if z-branch is actually used or how frequently! may be no need

Good point. I've added the optional ability to supply a branch name in 22533ba

Actually, I think this is wrong.
It doesn't say to create z-branch - it says to create a release branch from one of the branches (master, z etc). Where the z branch is created is absent from the docs so is out of scope for now. But It means the existing implementation was fine, so reverted.
9c8fb84

Having the 5.6.z auto created may be a good practice, since normally we should always backport the bug fixes as possible and when you want to do it, the branch would be ready. What is the practice at platform releases? We can use the same approach.

Probably one for @nishaatr to answer.

In Platform z-branch is created for MAJOR/MINOR. It will also updates version in master (MAJOR/MINOR ) and z-branch (PATCH). This is all automatic based on the supplied release type

prefer its automated here. So if BRANCH_NAME ends with .z then don't create z-branch, otherwise create one then update z-branch version to the next version (@ihsandemir is this correct?). For master we have this step

I think we can talk about z branch creation, but I'd like to do so seperately.
This PR automates an existing process - I don't want to confuse adding a new process at the same time.

By all means raise an issue in this repo so we can keep the discussion going?

[nishaatr]

forgot to mention about maintenance branch here it says create z-branch wondering if z-branch is actually used or how frequently! may be no need

Good point. I've added the optional ability to supply a branch name in 22533ba

Actually, I think this is wrong.
It doesn't say to create z-branch - it says to create a release branch from one of the branches (master, z etc). Where the z branch is created is absent from the docs so is out of scope for now. But It means the existing implementation was fine, so reverted.
9c8fb84

Having the 5.6.z auto created may be a good practice, since normally we should always backport the bug fixes as possible and when you want to do it, the branch would be ready. What is the practice at platform releases? We can use the same approach.

Probably one for @nishaatr to answer.

In Platform z-branch is created for MAJOR/MINOR. It will also updates version in master (MAJOR/MINOR ) and z-branch (PATCH). This is all automatic based on the supplied release type
prefer its automated here. So if BRANCH_NAME ends with .z then don't create z-branch, otherwise create one then update z-branch version to the next version (@ihsandemir is this correct?). For master we have this step

I think we can talk about z branch creation, but I'd like to do so seperately. This PR automates an existing process - I don't want to confuse adding a new process at the same time.

By all means raise an issue in this repo so we can keep the discussion going?

kind of is existing process

but oddly towards the end + plus uses tag for some reason - so different to Platform

Also, looks like 5.6.z was never created (so this definitely begs automatation)

no issue to do in another PR. I have raised #1371

[JackPGreen]

kind of is existing process

Sorry - I'd completely missed that it was already in the instructions as the stemp name was unclear. In hindsight that + milestones are pretty easy to automate. But let's do it one step at a time...