GithubHelp home page GithubHelp logo

Comments (14)

SethTisue avatar SethTisue commented on August 25, 2024 3

I work in many repos that have multiple active branches: in the Scala org (Scala itself, some of the module repos, etc), in the Lightbend org, and more generally in the course of my work on the Scala community build

as others have observed, there's really two pieces to this, one is the ability to pick a branch that isn't the GitHub default branch, the other is the ability to pick multiple branches

re: a non-default branch, sometimes the default branch isn't the most useful branch for scala-steward to target. in repos that do merges from older branches to newer branches, the best branch for scala-steward to target might be the oldest actively maintained branch. (why wouldn't that be the default branch, you might wonder? because the default branch is where new development takes place. but things like Scala version bumps, sbt version bumps, and testing library bumps aren't really new development) admittedly there is an obvious failure mode: if you only target the oldest branch, then you miss updates to dependencies that the oldest branch doesn't have. but the current scheme has an obvious failure mode too, which is that your older branches don't benefit from the steward at all.

re: multiple branches, I agree with Frank that just treating the branches separately would be a perfectly good initial starting point. some repos don't do regular merges (or any merges) from older branches to newer branches, and in those cases, the simple strategy would be fine. even in repos that do merge between branches, the simple version of the feature still wouldn't be terrible. maintainers could either 1) manually close redundant PRs, or 2) go ahead and merge redundant PRs and then sort out any merge conflicts at merge-forward time (and in many cases there wouldn't be any conflict, since git would notice that the change was already made)

from scala-steward.

pk044 avatar pk044 commented on August 25, 2024 3

I am currently implementing it following @fthomas's proposition posted on Gitter. I'll make a PR soon enough :)

from scala-steward.

SethTisue avatar SethTisue commented on August 25, 2024 3

@kbreidenbach perhaps it will be enough for you to simply change the default branch in your repo? I don't think steward hardcodes "master", I think it goes off the default-branch setting

from scala-steward.

fthomas avatar fthomas commented on August 25, 2024 3

#2281 made branch selection also available for users of the public Scala Steward instance, thanks to @alejandrohdezma! https://github.com/scala-steward-org/scala-steward/blob/master/docs/faq.md#can-scala-steward-update-multiple-branches-in-a-repository shows how the repos.md file needs to be updated to select a different branch or how to add multiple branches.

from scala-steward.

He-Pin avatar He-Pin commented on August 25, 2024

Should support multiple watched branches, maybe something like["akka2.4","master"]

from scala-steward.

rossabaker avatar rossabaker commented on August 25, 2024

How would multiple branches work? Would it submit a PR to each branch, and let the maintainers pick which PR to merge? Try to be smart about picking the first branch?

I have a similar use case. Just thinking about how it would work.

from scala-steward.

fthomas avatar fthomas commented on August 25, 2024

I don't maintain multiple branches in my projects so I don't have an intuition what would work best in such cases. A PR for each branch sounds like a simple strategy which could be refined with more practical experience of this feature.

from scala-steward.

manuelcueto avatar manuelcueto commented on August 25, 2024

A good first step would be to support choosing from which branch to checkout and create the PR to, defaulting to Master.
I don't think that creating multiple Prs for a single update would be helpful especially if CI pipelines are costly (time or resources)

from scala-steward.

milessabin avatar milessabin commented on August 25, 2024

shapeless would also benefit from this. There are two active development branches, master and shapeless-3. Scala Steward only targets the former ... it'd be great if it could update both.

from scala-steward.

callicles avatar callicles commented on August 25, 2024

We could use this as well at Datalogue.

Here is how we manage our projects.

Each is using master as the state of the latest release that's the default branch.
We then have release branches that follow the pattern release-x.x.x that enable us.

Ideally for us the ideal behavior would be that for each release-x.x.x branch the scala steward would go try to make the update and PR against that branch

In the case mentioned by @rossabaker, if one of the several PRs for the same version update gets merged, I imagine we could have the bot close the sister PRs automatically. Since a user might want to merge and update in upstream or downstream.

Hope this helps

from scala-steward.

kbreidenbach avatar kbreidenbach commented on August 25, 2024

Any news on the PR as we are trying to move away from the use of master as the trunk and would like a way to pick the branch name for scala steward to check for updates?

from scala-steward.

exoego avatar exoego commented on August 25, 2024

Closing as resolved.
My understanding is #2183 implemented branch selection feature.
Thanks @alejandrohdezma

from scala-steward.

alejandrohdezma avatar alejandrohdezma commented on August 25, 2024

This change will be available for users of the Scala Steward GitHub Action, once scala-steward-org/scala-steward-action#268 is merged. Allowing this in any other way (either repos.md or .scala-steward.conf) would involve a bigger refactor in Scala Steward.

from scala-steward.

fthomas avatar fthomas commented on August 25, 2024

Reopening because #2183 adds branch selection for users of the GitHub Action but not for users of the public Scala Steward instance.

from scala-steward.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.