With Scala 3 being released () we want to consolidate our GitHub setup, specifically in terms of transferring and renaming https://github.com/lampepfl/dotty to https://github.com/scala/scala3. We also intend to rename scala/scala to scala/scala2, but there’s no urgency so we’ll do that in a few months. For the scala/scala3 migration, we want to avoid it impacting any imminent patch releases, i.e. 3.0.1, so our paper-napkin plan is the following:
release 3.0.1-RC1, this week or next
after 6 weeks release 3.0.1
transfer and then rename the repo, and fix all the scripts/config
Which roughly puts us in the week of 5 July. By the way, the reason we can’t “just” move scala/scala to scala/scala2 and move the new repo into scala/scala is that it would break every existing URL to scala/scala.
I’m not really sure you can, but what about renaming the scala/scala repo to scala/2, lampepfl/dotty to scala/3, scala/bug to scala/2-bug and similar for whatever else should be renamed?
Thats an interesting idea. It turns out you can create a repo called “2”, but I still don’t think we should do it because that would be the default name when users clone or fork the repo.
Isn’t there a field for the fork name? I guess you would have to remember, but even if you don’t you just notice later and rename the repo. Not ideal, but scala/scala2 looks like an useless repetition
The only thing I would advice against would be using GitHub Discussions for feature requests. I’ve experimented with it quite a bit and it’s currently not suitable (no way to close requests or turn them into issues is the first major blocker for me).
As for the rest, scala/2 would be strange since git clone would produce a directory named 2. I’m fine with the repetition, and we already lived with it with scala/scala so no big deal there
Why not keep scala/scala for Scala 2, but rename the current main branch to 2.x? (and then move lampepfl/dotty into the main branch of scala/scala)
I guess the main issue is that unlike if we transferred lampepfl/dotty to scala/scala, there will be no automatic redirect from the former to the latter.
That can be fixed by keeping the 2.x branch called main and just set the main repo branch to 3.x, so new links go there and old ones pointing to main still go to 2.x
However this would potentially favor Scala 2 over Scala 3, idk
scala/scala hasn’t had a main/master branch for ages. It has 2.11.x, 2.12.x and 2.13.x. That said, the real problem with this approach is migrating the issues and PRs.
scala/bug contains many useful discussion about the evolution of the Scala language. Assuming that eventually everyone migrates to Scala 3.x in some time (it’s been two years since 2.13 came out), I think Scala 3.x should also inherit scala/bug.
Create a new repository scala/scala2-bug.
Transfer dotty issues into scala/bug programmatically.
Close fixed-in-Dotty issues in scala/bug, or transfer to scala/scala2-bug.
Pro:
Monotonically increasing numbering scheme Scala bugs that’s been going on since JIRA days.
It makes sense that Dotty had its own list of bugs during the development phase; now that it’s called Scala 3, we can transfer all the issues if all parties agree?
They should be transferred when you first move the scala-2 branches into lampepfl/dotty, then move scala/scala to scala/scala2-old, and finally move lampepfl/dotty to scala/scala.
(Then, scala/scala2-old may be archived.)
Then, we get the following benefits:
scala-3 is the scala, so it resides at scala/scala
all links to lampepfl/dotty are redirected
all links to scala/scala code still work (because they contain the branch name 2.13.x or alike)
all scala-3-issues and PRs are at scala/scala
all scala-2-issues are still at scala/bug (which may be moved to scala/scala2-bug)
all scala-2-PRs are archived (the ~15 open ones could be transferred manually)
everything is in one repo. When looking for “scala”, there is no “Oh, that’s in the other scala repo”
Disadvantages:
links to scala-2 PRs (scala/scala/pull) will break (and not be redirected to scala/scala2-old/pull)
everything is in one repo. As @Katrix pointed out this is hard to search within Github
Disclaimer: I assume it works like that, but we schould definitively test it beforehand
s/seperate/separate, the mnemonic is “pare” as in “paring knife”.
s/it's/its where “its own count” is like “his own count”.
s/scala2-old/scala-mature I think I already joked about not being ageist, and yes that is the spelling, as I learned.
it’s been two years since 2.13 came out
Let’s agree that pandemic year does not count.
I agree that if Scala 3 is the new normal, then folks should visit scala/scala to report bugs and contribute.
After listening to Odersky’s keynote on how Scala 3 came about, I also wish it had been developed on a branch. I also wish they hadn’t ditched partest just when it got better. I still can’t contribute a Scala 3 test without researching how. That is, there is a lot to say in favor of so-called synergy. Is that still a word?
We’ll do it eventually, but it is quite a large effort to migrate and adapt everyone’s work flow to the new system. We have to weigh convenience of having one repo against loss of productivity for some protracted amount of time for the people who fix the bugs today. My personal take is that we should undertake it once we have enough trained people to stay atop the open issues queue.
Since my dotty issues were moved to feature-requests and then from feature-requests to discussions, I’ve lost all sense that consolidation is a priority. I think the status quo is fine. The code calls itself dotty.
Another consideration is that small repositories are better than larger.
) we want to consolidate our GitHub setup, specifically in terms of transferring and renaming https://github.com/lampepfl/dotty to https://github.com/scala/scala3. We also intend to rename scala/scala to scala/scala2, but there’s no urgency so we’ll do that in a few months. For the scala/scala3 migration, we want to avoid it impacting any imminent patch releases, i.e. 3.0.1, so our paper-napkin plan is the following:
