Repository naming (loopback, loopback-next)

[bajtos]

At the moment, we have the following two "main" repositories on GitHub:

• https://github.com/strongloop/loopback hosts the original code base for versions 0.x to 3.x.
• https://github.com/strongloop/loopback-next hosts the new TypeScript code base for the version 4.x

I feel it's time to rethink the repository names to better reflect the current status of 3.x and 4.x versions:

• 3.x is in LTS mode and will go EOL next year
• 4.x is no longer "next", it's the current version

What new name should we pick for loopback repository? Few options that come to my mind: loopback3, loopback-legacy.

What new name to pick for loopback-next? I am reluctant to use loopback, I am concerned it will break all existing URLs. I am proposing to use loopback-core instead.

@strongloop/loopback-maintainers @strongloop/loopback-next thoughts?

[clayrisser]

loopforward 😆

[dhmlau]

I don't have strong preferences.

• For loopback, loopback3 or loopback-legacy seems good to me. loopback-legacy might be more suited in the sense that LB2 and LB3 (i guess there's a LB1 release) also share the same code base.
• For loopback-next, I'm good with loopback-core.

[jannyHou]

• For loopback 2 and 3, I am ok with loopback-legacy, or just stay with loopback to save the URL changing effort.

• For loopback 4, loopback-core is good to me. Some other ideas:

  • loopback-ts to imply it's written in TypeScript.
  • loopback4 to be straightforward.

[raymondfeng]

I’m -1 to rename loopback-next to loopback-core, which does not reflect all packages in the monorepo.

If I have to pick one, loopback-ts is acceptable.

[bajtos]

• loopback4 won't work when we release 5.0 version (and later 6.0, etc.)
• I can see how loopback-core can be problematic, considering the variety of packages hosted in this monorepo.
• loopback-ts is not great, but I can live with it. When I think about it, I like loopback-next more than loopback-ts.

[bajtos]

How about the name loopback-framework for the monorepo?

[rahulrkr08]

Some thoughts :)

• loopback-stacks
• loopback-platform

[nabdelgadir]

• For LoopBack 3: I like loopback-legacy.
  • I feel like we shouldn't keep it as loopback because it might be hard for a newcomer to know that it's not the current version.
• For LoopBack 4: +1 to loopback-framework

[b-admike]

My votes go to loopack-legacy for loopack repo and loopback-framework/loopback-ts/loopback-platform for lb-next monorepo.

[agnes512]

My votes:

• Loopback3: loopback-legacy
• Loopback4: loopback-framework

[dougal83]

• Loopback3: +1 loopback-legacy
• Loopback4: +1 loopback-framework (also loopback-toolkit, loopback-io)

[dhmlau]

@raymondfeng @bajtos , seems like the general consensus is:

• Loopback3: loopback-legacy
• Loopback4: loopback-framework

Are you good with this naming change?
If we need to change it, when would be a good time? Do we need to set up some redirect mechanism if someone goes to https://github.com/strongloop/loopback-next, it will be redirected to the new repo url?

[raymondfeng]

Stepping back, does the name of the github repo really matter so much? If not, I would rather keep them as is for now until we cannot live with it. It would be fairly disruptive to rename both of them. Maybe it's better spending the bandwidth on other things.

[bajtos]

Do we need to set up some redirect mechanism if someone goes to https://github.com/strongloop/loopback-next, it will be redirected to the new repo url?

I believe this should be handled by GitHub automatically.

Stepping back, does the name of the github repo really matter so much? If not, I would rather keep them as is for now until we cannot live with it. It would be fairly disruptive to rename both of them. Maybe it's better spending the bandwidth on other things.

My main concern is that the current naming scheme creates the impression that LB 3.x (loopback) is the main version to use and LB 4.x (loopback-next) is something coming in the future.

At minimum, I'd like to rename loopback to loopback-legacy.

Thoughts?

[JonnyBGod]

loopback and loopback-next are two different beasts all together more so as of now they do not have any sort of feature parity.

In my opinion loopback-next as is is not production ready as loopback is unless you treat it as a completely different project.

So, in my opinion I see two different options here:

• keep everything as is until we have a closer feature parity and then just treat lb-next as the next major version of loopback
• treat lb-next as a new project and find a new name for it

loopback is still used a lot more the next and renaming it would create a major breaking change for a stable project and a lot of projects/people would have to react to it.

Using a good project name to sell a new project does not seam to be fair treatment for any of them and it would annoy a lot of people.

I think it is premature to have this discussion. Let complete loopback-next and then call it loopback@4.x

[bajtos]

@JonnyBGod thank you for the comment. I agree that loopback-next is very different from loopback. This is already captured in npm package names - loopback-next packages use names like @loopback/core and @loopback/rest, while LB 3.x packages are loopback, strong-remoting, etc.

Even when LB4 (or later) reaches feature parity with LB 3.x, it will keep using the new package names. As far as our current plans go, there is no intention to publish loopback@4.0.0.

This discussion is focused on GitHub repository names. Even if we rename the repository from strongloop/loopback to strongloop/loopback-legacy, the package name will stay loopback. There will be no breaking change for people consuming loopback via package.json dependencies.

[bajtos]

@dhmlau @raymondfeng ping, now that LB3 is in Maintenance LTS, is it perhaps time to move forward and rename one or both repositories?

seems like the general consensus is:

• Loopback3: loopback-legacy
• Loopback4: loopback-framework

[stale[bot]]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.