Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repository layout: adopt a standard master branch with all supported versions #248

Open
1 of 3 tasks
jouvin opened this issue Nov 8, 2024 · 4 comments
Open
1 of 3 tasks
Assignees
Milestone

Comments

@jouvin
Copy link
Contributor

jouvin commented Nov 8, 2024

For reasons I forgot, when we created this repo at SVN -> Git migration time, we opted for a branch per middleware version and no master branch. It turned out not to be a great idea: it makes everything more complicated, including:

  • A release must tag several branches
  • Fixing a problem affecting several middleware versions requires several PRs
  • get-template-library must do complicated things to select all the branches to checkout
  • Obsoleting a branch requires renaming it with a .obsolete suffix rather than removing the corresponding set of templates in the master branch

My proposal is to move to a standard structure with a master branch and have a first level directory representing the middleware version the templates must be used for, e.g. umd-4, umd-5 ... and to adapt the release tools and get-template-library to deal with this new/simpler structure.

Does anybody disagree? It should be transparent to template-library-grid users, in fact it should make their life easier. If there is an agreement, do you want to do it in the upcoming release, 24.10? Adding explicitely @jrha and @Pansanel .

Proposed plan includes:

  • Create new main branch from umd-4 branch
  • Adapt release tools to the new (simpler) layout
  • Update the repository structure description in get-library-template

Ideally, should be done before adding umd-5 templates to simplify the operation and avoid the need to "merge" 2 branches with their history.

@jouvin jouvin assigned jrha, Pansanel and jouvin and unassigned jrha and Pansanel Nov 8, 2024
@jrha
Copy link
Member

jrha commented Nov 8, 2024

Duplicate of quattor/release#309 ?

@jrha jrha marked this as a duplicate of quattor/release#309 Nov 8, 2024
@jrha
Copy link
Member

jrha commented Nov 8, 2024

We are definitely not doing it this (24.10) release though, it will break too many things in the release process.

@jrha jrha added this to the 25.next milestone Nov 8, 2024
@jouvin
Copy link
Contributor Author

jouvin commented Nov 8, 2024

No I don't think it duplicates quattor/release#309 that I forgot and tend to disagree with... Ok, I'll try to make the change once 24.10 is released.

@jrha
Copy link
Member

jrha commented Dec 3, 2024

quattor/release#370

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants