Add a check for updated version before deployment by paulbalandan · Pull Request #6802 · codeigniter4/CodeIgniter4

paulbalandan · 2022-11-01T08:45:27Z

Description
"Successful" run: https://github.com/paulbalandan/CodeIgniter4/actions/runs/3369749982/jobs/5589787478

Checklist:

Securely signed commits
Component(s) with PHPDoc blocks, only if necessary or adds value
Unit testing, with >80% coverage
User guide updated
Conforms to style guide

MGatner

I brought this up on the release thread in response to a contributor comment, but we need to decide what a "hotfix" looks like. This seems to be a vote for "go back through the entire release process" so that our version numbers are always consistent. I think that is probably the best approach, since we're not actually pushing anything to "production" to begin with. Alternatives would be to release sub-versions like 4.2.8.1 or 4.2.8-hotfix, or to delete tags from all distributable repos and redo the release.

kenjis · 2022-11-01T11:56:18Z

If we are going to follow Semantic Versioning, I think we cannot use 4.2.8.1 or 4.2.8-hotfix.
Also, we cannot remove the tags.
Am I wrong?

paulbalandan · 2022-11-01T13:45:57Z

I think redoing the release is the best approach, but I'm not sure if the new tag's SHA will be picked up by packagist.

MGatner · 2022-11-02T10:54:53Z

Packagist will update if you remove a tag and re-release it. This is my approach on small libraries when I make a mistake. We could do that here as well, just have to delete the tags from the distributable repos too.

Sticking with SemVer is best. It looks like we could append "build metadata" like v4.0.8+hotfix.1 but that seems more of a hack than a supported approach. So let's go with new release or removing tags.

kenjis · 2022-11-02T11:09:19Z

When we use this PR,
if we forget to update the version number, the framework deploy will stop.
But in this repository the release was done already?

paulbalandan · 2022-11-02T11:28:31Z

... But in this repository the release was done already?

Yes, because the release payload from this repo will be used in creating the respective releases in the 3 repos through actions/github-script

MGatner · 2022-11-03T10:19:31Z

I think that's fine. Deleting tags isn't as big a deal as it seems, and if the Action stops it from happening on the distributables then we are pretty much guaranteed nobody has been affected.

kenjis · 2022-11-03T10:33:48Z

Yes, this repository is not a Composer package.
Removing tags/releases is not a big deal if we do it quickly.

paulbalandan · 2022-11-01T08:45:27Z

Description
"Successful" run: https://github.com/paulbalandan/CodeIgniter4/actions/runs/3369749982/jobs/5589787478

Checklist:

Securely signed commits
Component(s) with PHPDoc blocks, only if necessary or adds value
Unit testing, with >80% coverage
User guide updated
Conforms to style guide

MGatner

I brought this up on the release thread in response to a contributor comment, but we need to decide what a "hotfix" looks like. This seems to be a vote for "go back through the entire release process" so that our version numbers are always consistent. I think that is probably the best approach, since we're not actually pushing anything to "production" to begin with. Alternatives would be to release sub-versions like 4.2.8.1 or 4.2.8-hotfix, or to delete tags from all distributable repos and redo the release.

kenjis · 2022-11-01T11:56:18Z

If we are going to follow Semantic Versioning, I think we cannot use 4.2.8.1 or 4.2.8-hotfix.
Also, we cannot remove the tags.
Am I wrong?

paulbalandan · 2022-11-01T13:45:57Z

I think redoing the release is the best approach, but I'm not sure if the new tag's SHA will be picked up by packagist.

MGatner · 2022-11-02T10:54:53Z

Packagist will update if you remove a tag and re-release it. This is my approach on small libraries when I make a mistake. We could do that here as well, just have to delete the tags from the distributable repos too.

Sticking with SemVer is best. It looks like we could append "build metadata" like v4.0.8+hotfix.1 but that seems more of a hack than a supported approach. So let's go with new release or removing tags.

kenjis · 2022-11-02T11:09:19Z

When we use this PR,
if we forget to update the version number, the framework deploy will stop.
But in this repository the release was done already?

paulbalandan · 2022-11-02T11:28:31Z

... But in this repository the release was done already?

Yes, because the release payload from this repo will be used in creating the respective releases in the 3 repos through actions/github-script

MGatner · 2022-11-03T10:19:31Z

I think that's fine. Deleting tags isn't as big a deal as it seems, and if the Action stops it from happening on the distributables then we are pretty much guaranteed nobody has been affected.

kenjis · 2022-11-03T10:33:48Z

Yes, this repository is not a Composer package.
Removing tags/releases is not a big deal if we do it quickly.

paulbalandan · 2022-11-01T08:45:27Z

Description
"Successful" run: https://github.com/paulbalandan/CodeIgniter4/actions/runs/3369749982/jobs/5589787478

Checklist:

Securely signed commits
Component(s) with PHPDoc blocks, only if necessary or adds value
Unit testing, with >80% coverage
User guide updated
Conforms to style guide

MGatner

I brought this up on the release thread in response to a contributor comment, but we need to decide what a "hotfix" looks like. This seems to be a vote for "go back through the entire release process" so that our version numbers are always consistent. I think that is probably the best approach, since we're not actually pushing anything to "production" to begin with. Alternatives would be to release sub-versions like 4.2.8.1 or 4.2.8-hotfix, or to delete tags from all distributable repos and redo the release.

kenjis · 2022-11-01T11:56:18Z

If we are going to follow Semantic Versioning, I think we cannot use 4.2.8.1 or 4.2.8-hotfix.
Also, we cannot remove the tags.
Am I wrong?

paulbalandan · 2022-11-01T13:45:57Z

I think redoing the release is the best approach, but I'm not sure if the new tag's SHA will be picked up by packagist.

MGatner · 2022-11-02T10:54:53Z

Packagist will update if you remove a tag and re-release it. This is my approach on small libraries when I make a mistake. We could do that here as well, just have to delete the tags from the distributable repos too.

Sticking with SemVer is best. It looks like we could append "build metadata" like v4.0.8+hotfix.1 but that seems more of a hack than a supported approach. So let's go with new release or removing tags.

kenjis · 2022-11-02T11:09:19Z

When we use this PR,
if we forget to update the version number, the framework deploy will stop.
But in this repository the release was done already?

paulbalandan · 2022-11-02T11:28:31Z

... But in this repository the release was done already?

Yes, because the release payload from this repo will be used in creating the respective releases in the 3 repos through actions/github-script

MGatner · 2022-11-03T10:19:31Z

I think that's fine. Deleting tags isn't as big a deal as it seems, and if the Action stops it from happening on the distributables then we are pretty much guaranteed nobody has been affected.

kenjis · 2022-11-03T10:33:48Z

Yes, this repository is not a Composer package.
Removing tags/releases is not a big deal if we do it quickly.

paulbalandan · 2022-11-01T08:45:27Z

Description
"Successful" run: https://github.com/paulbalandan/CodeIgniter4/actions/runs/3369749982/jobs/5589787478

Checklist:

Securely signed commits
Component(s) with PHPDoc blocks, only if necessary or adds value
Unit testing, with >80% coverage
User guide updated
Conforms to style guide

MGatner

I brought this up on the release thread in response to a contributor comment, but we need to decide what a "hotfix" looks like. This seems to be a vote for "go back through the entire release process" so that our version numbers are always consistent. I think that is probably the best approach, since we're not actually pushing anything to "production" to begin with. Alternatives would be to release sub-versions like 4.2.8.1 or 4.2.8-hotfix, or to delete tags from all distributable repos and redo the release.

kenjis · 2022-11-01T11:56:18Z

If we are going to follow Semantic Versioning, I think we cannot use 4.2.8.1 or 4.2.8-hotfix.
Also, we cannot remove the tags.
Am I wrong?

paulbalandan · 2022-11-01T13:45:57Z

I think redoing the release is the best approach, but I'm not sure if the new tag's SHA will be picked up by packagist.

MGatner · 2022-11-02T10:54:53Z

Packagist will update if you remove a tag and re-release it. This is my approach on small libraries when I make a mistake. We could do that here as well, just have to delete the tags from the distributable repos too.

Sticking with SemVer is best. It looks like we could append "build metadata" like v4.0.8+hotfix.1 but that seems more of a hack than a supported approach. So let's go with new release or removing tags.

kenjis · 2022-11-02T11:09:19Z

When we use this PR,
if we forget to update the version number, the framework deploy will stop.
But in this repository the release was done already?

paulbalandan · 2022-11-02T11:28:31Z

... But in this repository the release was done already?

Yes, because the release payload from this repo will be used in creating the respective releases in the 3 repos through actions/github-script

MGatner · 2022-11-03T10:19:31Z

I think that's fine. Deleting tags isn't as big a deal as it seems, and if the Action stops it from happening on the distributables then we are pretty much guaranteed nobody has been affected.

kenjis · 2022-11-03T10:33:48Z

Yes, this repository is not a Composer package.
Removing tags/releases is not a big deal if we do it quickly.

paulbalandan · 2022-11-01T08:45:27Z

Description
"Successful" run: https://github.com/paulbalandan/CodeIgniter4/actions/runs/3369749982/jobs/5589787478

Checklist:

Securely signed commits
Component(s) with PHPDoc blocks, only if necessary or adds value
Unit testing, with >80% coverage
User guide updated
Conforms to style guide

MGatner

I brought this up on the release thread in response to a contributor comment, but we need to decide what a "hotfix" looks like. This seems to be a vote for "go back through the entire release process" so that our version numbers are always consistent. I think that is probably the best approach, since we're not actually pushing anything to "production" to begin with. Alternatives would be to release sub-versions like 4.2.8.1 or 4.2.8-hotfix, or to delete tags from all distributable repos and redo the release.

kenjis · 2022-11-01T11:56:18Z

If we are going to follow Semantic Versioning, I think we cannot use 4.2.8.1 or 4.2.8-hotfix.
Also, we cannot remove the tags.
Am I wrong?

paulbalandan · 2022-11-01T13:45:57Z

I think redoing the release is the best approach, but I'm not sure if the new tag's SHA will be picked up by packagist.

MGatner · 2022-11-02T10:54:53Z

Packagist will update if you remove a tag and re-release it. This is my approach on small libraries when I make a mistake. We could do that here as well, just have to delete the tags from the distributable repos too.

Sticking with SemVer is best. It looks like we could append "build metadata" like v4.0.8+hotfix.1 but that seems more of a hack than a supported approach. So let's go with new release or removing tags.

kenjis · 2022-11-02T11:09:19Z

When we use this PR,
if we forget to update the version number, the framework deploy will stop.
But in this repository the release was done already?

paulbalandan · 2022-11-02T11:28:31Z

... But in this repository the release was done already?

Yes, because the release payload from this repo will be used in creating the respective releases in the 3 repos through actions/github-script

MGatner · 2022-11-03T10:19:31Z

I think that's fine. Deleting tags isn't as big a deal as it seems, and if the Action stops it from happening on the distributables then we are pretty much guaranteed nobody has been affected.

kenjis · 2022-11-03T10:33:48Z

Yes, this repository is not a Composer package.
Removing tags/releases is not a big deal if we do it quickly.

paulbalandan · 2022-11-01T08:45:27Z

Description
"Successful" run: https://github.com/paulbalandan/CodeIgniter4/actions/runs/3369749982/jobs/5589787478

Checklist:

Securely signed commits
Component(s) with PHPDoc blocks, only if necessary or adds value
Unit testing, with >80% coverage
User guide updated
Conforms to style guide

MGatner

I brought this up on the release thread in response to a contributor comment, but we need to decide what a "hotfix" looks like. This seems to be a vote for "go back through the entire release process" so that our version numbers are always consistent. I think that is probably the best approach, since we're not actually pushing anything to "production" to begin with. Alternatives would be to release sub-versions like 4.2.8.1 or 4.2.8-hotfix, or to delete tags from all distributable repos and redo the release.

kenjis · 2022-11-01T11:56:18Z

If we are going to follow Semantic Versioning, I think we cannot use 4.2.8.1 or 4.2.8-hotfix.
Also, we cannot remove the tags.
Am I wrong?

paulbalandan · 2022-11-01T13:45:57Z

I think redoing the release is the best approach, but I'm not sure if the new tag's SHA will be picked up by packagist.

MGatner · 2022-11-02T10:54:53Z

Packagist will update if you remove a tag and re-release it. This is my approach on small libraries when I make a mistake. We could do that here as well, just have to delete the tags from the distributable repos too.

Sticking with SemVer is best. It looks like we could append "build metadata" like v4.0.8+hotfix.1 but that seems more of a hack than a supported approach. So let's go with new release or removing tags.

kenjis · 2022-11-02T11:09:19Z

When we use this PR,
if we forget to update the version number, the framework deploy will stop.
But in this repository the release was done already?

paulbalandan · 2022-11-02T11:28:31Z

... But in this repository the release was done already?

Yes, because the release payload from this repo will be used in creating the respective releases in the 3 repos through actions/github-script

MGatner · 2022-11-03T10:19:31Z

I think that's fine. Deleting tags isn't as big a deal as it seems, and if the Action stops it from happening on the distributables then we are pretty much guaranteed nobody has been affected.

kenjis · 2022-11-03T10:33:48Z

Yes, this repository is not a Composer package.
Removing tags/releases is not a big deal if we do it quickly.

paulbalandan · 2022-11-01T08:45:27Z

Description
"Successful" run: https://github.com/paulbalandan/CodeIgniter4/actions/runs/3369749982/jobs/5589787478

Checklist:

Securely signed commits
Component(s) with PHPDoc blocks, only if necessary or adds value
Unit testing, with >80% coverage
User guide updated
Conforms to style guide

MGatner

I brought this up on the release thread in response to a contributor comment, but we need to decide what a "hotfix" looks like. This seems to be a vote for "go back through the entire release process" so that our version numbers are always consistent. I think that is probably the best approach, since we're not actually pushing anything to "production" to begin with. Alternatives would be to release sub-versions like 4.2.8.1 or 4.2.8-hotfix, or to delete tags from all distributable repos and redo the release.

kenjis · 2022-11-01T11:56:18Z

If we are going to follow Semantic Versioning, I think we cannot use 4.2.8.1 or 4.2.8-hotfix.
Also, we cannot remove the tags.
Am I wrong?

paulbalandan · 2022-11-01T13:45:57Z

I think redoing the release is the best approach, but I'm not sure if the new tag's SHA will be picked up by packagist.

MGatner · 2022-11-02T10:54:53Z

Packagist will update if you remove a tag and re-release it. This is my approach on small libraries when I make a mistake. We could do that here as well, just have to delete the tags from the distributable repos too.

Sticking with SemVer is best. It looks like we could append "build metadata" like v4.0.8+hotfix.1 but that seems more of a hack than a supported approach. So let's go with new release or removing tags.

kenjis · 2022-11-02T11:09:19Z

When we use this PR,
if we forget to update the version number, the framework deploy will stop.
But in this repository the release was done already?

paulbalandan · 2022-11-02T11:28:31Z

... But in this repository the release was done already?

Yes, because the release payload from this repo will be used in creating the respective releases in the 3 repos through actions/github-script

MGatner · 2022-11-03T10:19:31Z

I think that's fine. Deleting tags isn't as big a deal as it seems, and if the Action stops it from happening on the distributables then we are pretty much guaranteed nobody has been affected.

kenjis · 2022-11-03T10:33:48Z

Yes, this repository is not a Composer package.
Removing tags/releases is not a big deal if we do it quickly.

paulbalandan · 2022-11-01T08:45:27Z

Description
"Successful" run: https://github.com/paulbalandan/CodeIgniter4/actions/runs/3369749982/jobs/5589787478

Checklist:

Securely signed commits
Component(s) with PHPDoc blocks, only if necessary or adds value
Unit testing, with >80% coverage
User guide updated
Conforms to style guide

MGatner

I brought this up on the release thread in response to a contributor comment, but we need to decide what a "hotfix" looks like. This seems to be a vote for "go back through the entire release process" so that our version numbers are always consistent. I think that is probably the best approach, since we're not actually pushing anything to "production" to begin with. Alternatives would be to release sub-versions like 4.2.8.1 or 4.2.8-hotfix, or to delete tags from all distributable repos and redo the release.

kenjis · 2022-11-01T11:56:18Z

If we are going to follow Semantic Versioning, I think we cannot use 4.2.8.1 or 4.2.8-hotfix.
Also, we cannot remove the tags.
Am I wrong?

paulbalandan · 2022-11-01T13:45:57Z

I think redoing the release is the best approach, but I'm not sure if the new tag's SHA will be picked up by packagist.

MGatner · 2022-11-02T10:54:53Z

Packagist will update if you remove a tag and re-release it. This is my approach on small libraries when I make a mistake. We could do that here as well, just have to delete the tags from the distributable repos too.

Sticking with SemVer is best. It looks like we could append "build metadata" like v4.0.8+hotfix.1 but that seems more of a hack than a supported approach. So let's go with new release or removing tags.

kenjis · 2022-11-02T11:09:19Z

When we use this PR,
if we forget to update the version number, the framework deploy will stop.
But in this repository the release was done already?

paulbalandan · 2022-11-02T11:28:31Z

... But in this repository the release was done already?

Yes, because the release payload from this repo will be used in creating the respective releases in the 3 repos through actions/github-script

MGatner · 2022-11-03T10:19:31Z

I think that's fine. Deleting tags isn't as big a deal as it seems, and if the Action stops it from happening on the distributables then we are pretty much guaranteed nobody has been affected.

kenjis · 2022-11-03T10:33:48Z

Yes, this repository is not a Composer package.
Removing tags/releases is not a big deal if we do it quickly.

kenjis added the github_actions Pull requests that update Github_actions code label Nov 1, 2022

kenjis reviewed Nov 1, 2022
View reviewed changes

Comment thread.github/workflows/deploy-distributables.yml Outdated

paulbalandan force-pushed the check-version branch 2 times, most recently from 6c01dc8 to 446d3f7Compare November 1, 2022 10:54

MGatner reviewed Nov 1, 2022
View reviewed changes

Comment thread.github/workflows/deploy-distributables.yml

paulbalandan marked this pull request as draft November 1, 2022 11:05

paulbalandan force-pushed the check-version branch 6 times, most recently from 3db1397 to 460b8a4Compare November 1, 2022 13:25

paulbalandan added 4 commits November 1, 2022 21:28

Add check-version job
7f95f7d

Move contents of deploy-userguide to deploy-framework
cd4bff3

Rename to deploy-distributables.yml
884a8e7

Update admin/RELEASE.md
ebf7e66

paulbalandan force-pushed the check-version branch from 460b8a4 to ebf7e66Compare November 1, 2022 13:36

paulbalandan marked this pull request as ready for review November 1, 2022 13:38

MGatner approved these changes Nov 3, 2022
View reviewed changes

kenjis approved these changes Nov 3, 2022
View reviewed changes

paulbalandan merged commit 30fd482 into codeigniter4:developNov 4, 2022

paulbalandan deleted the check-version branch November 4, 2022 02:02

kenjis mentioned this pull request Aug 25, 2023
Dev: Deploy Distributable Repos failed #7854
Closed