Versioned release, changelog etc. #4

Open
opened 2021-11-11 10:21:12 +00:00 by 3wordchant · 2 comments
Owner
  • Decide how to handle app version vs. co-op cloud package version in this franken-repo
  • Choose an initial app version number
  • Make a changelog file
  • Make an initial tagged app release
  • Document app release process
  • Choose an initial package version number (if different to the app)
  • Make an initial package release
  • Document the package release process
- [ ] Decide how to handle app version vs. co-op cloud package version in this franken-repo - [ ] Choose an initial app version number - [ ] Make a changelog file - [x] Make an initial tagged app release - [ ] Document app release process - [x] Choose an initial package version number (if different to the app) - [x] Make an initial package release - [ ] Document the package release process
decentral1se added the
enhancement
label 2024-01-11 13:34:31 +00:00
Author
Owner

Thoughts, 3 years later 🫠

Decide how to handle app version vs. co-op cloud package version in this franken-repo

App version = changes to backup.py.

Co-op Cloud package version = changes to recipe.

For example, starting with 1.0.0+2.0.0 (which is what it would be if we released today):

  • "patch" change to recipe: 1.0.1+2.0.0
  • "patch" change to backup.py: increment both, so 1.0.1+2.0.1

Choose an initial app version number

I (semi arbitrarily?) called the image built from the bb2-classic branch 1.0.0, so I suggest we start the new version at 2.0.0.

Make a changelog file

Added a stub

Document app release process
Document the package release process

If every new "app" release also increments the Co-op Cloud recipe version (I think it should, as above) then I think "app release" = "packaging release" = bump version in compose.yml then abra recipe release backup-bot-two.

Thoughts @moritz @p4u1 @knoflook @decentral1se ?

Thoughts, 3 years later 🫠 > Decide how to handle app version vs. co-op cloud package version in this franken-repo App version = changes to `backup.py`. Co-op Cloud package version = changes to recipe. For example, starting with `1.0.0+2.0.0` (which is what it would be if we released today): * "patch" change to recipe: `1.0.1+2.0.0` * "patch" change to `backup.py`: increment both, so `1.0.1+2.0.1` > Choose an initial app version number I (semi arbitrarily?) called [the image built from the `bb2-classic` branch](https://git.coopcloud.tech/coop-cloud/-/packages/container/backup-bot-two/1.0.0) `1.0.0`, so I suggest we start the new version at 2.0.0. > Make a changelog file [Added a stub](https://git.coopcloud.tech/coop-cloud/backup-bot-two/src/branch/main/CHANGELOG.md) > Document app release process > Document the package release process If every new "app" release also increments the Co-op Cloud recipe version (I think it should, as above) then I think "app release" = "packaging release" = bump version in `compose.yml` then `abra recipe release backup-bot-two`. Thoughts @moritz @p4u1 @knoflook @decentral1se ?
Member

I would like to apply the sames rules as discussed in coop-cloud/organising#578 (comment)
This would mean:

  • "patch" change to recipe: 1.0.1+2.0.0
  • "patch" change to backup.py: 1.1.0+2.0.1
    • because bumping the image version would result in a minor recipe release

Then you can still release in-between recipe patches without updating the image.

I (semi arbitrarily?) called the image built from the bb2-classic branch 1.0.0, so I suggest we start the new version at 2.0.0.

👍

If every new "app" release also increments the Co-op Cloud recipe version (I think it should, as above) then I think "app release" = "packaging release" = bump version in compose.yml then abra recipe release backup-bot-two.

👍

I would like to apply the sames rules as discussed in https://git.coopcloud.tech/coop-cloud/organising/issues/578#issuecomment-19782 This would mean: - "patch" change to recipe: `1.0.1+2.0.0` - "patch" change to backup.py: `1.1.0+2.0.1` - because bumping the image version would result in a minor recipe release Then you can still release in-between recipe patches without updating the image. > I (semi arbitrarily?) called the image built from the bb2-classic branch 1.0.0, so I suggest we start the new version at 2.0.0. 👍 > If every new "app" release also increments the Co-op Cloud recipe version (I think it should, as above) then I think "app release" = "packaging release" = bump version in compose.yml then abra recipe release backup-bot-two. 👍
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/backup-bot-two#4
No description provided.