search

ubiquity-os / permit-generation

A standalone module to generate permits.
1 stars 19 forks source link

chore(main): release 1.4.0 #34

Closed github-actions[bot] closed 3 months ago

github-actions[bot] commented 4 months ago

:robot: I have created a release beep boop

1.4.0 (2024-07-08)

⚠ BREAKING CHANGES

Features

Bug Fixes

Miscellaneous Chores

This PR was generated with Release Please. See documentation.

gentlementlegen commented 4 months ago

@rndquu I added an empty commit that bumped the version to 1.4.0 here so going forward it should not downgrade the version anymore. I will also fix Knip and Jest tests since I notice they are not fixed like we did in other repos. Hopefully #28 should be fixed afterwards!

rndquu commented 4 months ago

@gentlementlegen So we should:

  1. Merge this PR into main
  2. Then merge main into development

Correct?

gentlementlegen commented 4 months ago

@rndquu No need to merge main into development, just merging into main.

rndquu commented 4 months ago

@rndquu No need to merge main into development, just merging into main.

But this way the main branch will have v1.4.0 while the development branch will still be v1.3.1

gentlementlegen commented 4 months ago

@rndquu We can merge it back, it is not really important as the version is based on the conventional commit comments and not on the tags of the branch / repo nor the package version. But to keep it in sync we can do so.

rndquu commented 3 months ago

@rndquu We can merge it back, it is not really important as the version is based on the conventional commit comments and not on the tags of the branch / repo nor the package version. But to keep it in sync we can do so.

It's important for a developer to keep versions in sync. When you git clone https://github.com/ubiquibot/permit-generation you get v1.3.1 from the development branch while the published one would be v1.4.0 so it's literally the 1st question "How to get the latest version?".

What is the expected flow of using release-please workflow, this one?

This PR introduces a different flow:

  1. A change is made in the development
  2. release-please bumps the version and creates a PR with updated version to the main branch
  3. We merge main into development to keep versions in sync

I'm trying to find out what approach we should use for all of the ubiquity repositories.

gentlementlegen commented 3 months ago

The version should never be manually changed that's why I believed it wouldn't matter (rest of the code is in sync). The difference in version happens because we use development as the default and main as the production.

Current flow within this PR is:

rndquu commented 3 months ago

The version should never be manually changed that's why I believed it wouldn't matter (rest of the code is in sync). The difference in version happens because we use development as the default and main as the production.

Current flow within this PR is:

  • a push is made to main
  • release please bumps the version, creates a changelog, which targets main
  • PR is merged, triggers publishing of the package from the main branch

How does the development branch sync the package.json version from the main branch?

gentlementlegen commented 3 months ago

Well ideally our main branch should be the release branch. But as you said, let's merge back main into develop in the meantime!

rndquu commented 3 months ago

Well ideally our main branch should be the release branch. But as you said, let's merge back main into develop in the meantime!

So the flow is:

  1. Changes are made in the development branch
  2. We manually merge development into main
  3. release-please bumps the version and creates a PR with updated version to the main branch
  4. We manually merge main into development to keep package.json version in sync
gentlementlegen commented 3 months ago

Correct. Also note that the deployment of the package happens after step 3 is completed.

github-actions[bot] commented 3 months ago

:robot: Created releases: