PyLoT Versioning #2

New Issue

sebastianw · 2021-03-28T12:49:36+02:00

sebastianw commented

2021-03-28 12:49:36 +02:00

There is a version script available that takes the RELEASE-VERSION into account. The file doesn't exist though. The last tag was given on the branch in the github repository. We should consider making the versioning applicable to the gitea hosting as well.

Moreover, is hosting on GitHub needed anymore. Linking to gitea might be a solution as well.

There is a version script available that takes the `RELEASE-VERSION` into account. The file doesn't exist though. The last tag was given on the branch in the github repository. We should consider making the versioning applicable to the gitea hosting as well. Moreover, is hosting on GitHub needed anymore. Linking to gitea might be a solution as well.

sebastianw referenced this issue

2021-03-28 12:55:34 +02:00

Milestones for structured development #3

sebastianw self-assigned this 2021-03-28 12:56:35 +02:00

sebastianw commented

2023-04-07 10:43:16 +02:00

Next step is to define the next version number to be released. This needs to be done in a meeting with the main stakeholders of the project. In the meeting also the milestone bugfixes/features/improvements need to be defined.

The branching concept needs to be overhauled to make reasonable release preparation possible.

rebase master to current developbranch
add release branches for proper release preparation of the next release (i.e. release/v<major>.<minor>)

Next step is to define the next version number to be released. This needs to be done in a meeting with the main stakeholders of the project. In the meeting also the milestone bugfixes/features/improvements need to be defined. The branching concept needs to be overhauled to make reasonable release preparation possible. - [ ] rebase `master` to current `develop`branch - [ ] add `release` branches for proper release preparation of the next release (i.e. `release/v<major>.<minor>`)

sebastianw commented

2023-04-07 20:51:00 +02:00

Rebasing of the old master to current develop is not possible since they diverge to much. As there are no tags on the master in gitea I would simply rename the old master to something like legacy_master. By this it would be possible to work with standard branching conventions and rename develop to master do the development on dedicated branches and control code contirbutions by pull requests on the master.

Rebasing of the old `master` to current `develop` is not possible since they diverge to much. As there are no tags on the `master` in gitea I would simply rename the old `master` to something like `legacy_master`. By this it would be possible to work with standard branching conventions and rename `develop` to `master` do the development on dedicated branches and control code contirbutions by pull requests on the `master`.

sebastianw added the

management

label 2023-04-10 09:03:20 +02:00

sebastianw referenced this issue

2023-04-11 18:08:18 +02:00

Delete not needed branches #8

sebastianw referenced this issue

2023-04-11 18:13:11 +02:00

Clean Code Refurbishment #4

Sign in to join this conversation.