Should we prepare a new repository for new frontend or keep using same repo?

[KoukiHama]

Both have pros and cons.

[heliocastro]

Same Repository

For same repository, there's the cost of develop in a different branch and keep the main/stabilisation branch up to date.
New features need to o analysed case by case to be included in the releases/18 branch.
Breaking changes that aren't critical bug fixes should be forbidden on the releases/18 branch

This is an brief bullet point idea

• A new releases/18 branch will be created
• main branch is temporary locked
• New branch stabilisation is created to do all adaptations
• Commits with fixes should be done on 18 branch and forwarded port automatically to branch stabilisation
• Intermediary releases of releases/18 branch can be done in a regular interval
• When branch stabilisation enters in build state, merge on main branch
• Unlock main branch
• delete branch stabilisation

---
title: Same Repository
---
%%{init: { 'logLevel': 'debug', 'theme': 'forest' } }%%
gitGraph
  commit id: "Release 18.1" tag: "sw360-18.1.0-M1"
  branch stabilisation
  branch releases/18
  checkout releases/18
  commit
  checkout stabilisation
   merge releases/18
  checkout releases/18
  commit
  checkout stabilisation
  commit
  commit
  commit
  merge releases/18
  checkout releases/18
  commit tag: "sw360-18.1.1-M1" type: HIGHLiGHT
  checkout stabilisation
  merge releases/18
  commit
  commit id: "Stable" type: HIGHLIGHT
  checkout main
  merge stabilisation
  commit
  commit
  checkout releases/18
  commit
  checkout main
  merge releases/18
  commit
  checkout releases/18
  commit
  checkout main
  merge releases/18
 commit

Loading

[heliocastro]

Different Repositories

For a new repository, complexity arises on commit in two different codebases every single commit.

The probable steps:

• Create a new repository called sw360next on eclipse-sw360 organization.
• Start clean as checking out only HEAD top commits, loose history, starting from scratch on code. OR
• Full clone sw360 repository and remove all unneeded parts
• Do regular commits on sw360 as bug fixes and non break features. No Liferay UI changes allowed
• Cherry pick commit, rebase sw360next codebase and push on main automated
• Get the commit, apply and rebase on sw360next codebase, commit in main manually if automation fail