Can this fork be an excuse for major breaking changes?

[samualtnorman]

I'm sure there's many things people want in rust but will never happen because it'd break backwards compatibility.
This fork is free from all of that.

If so should probably reset the version number to 0.0.1 or something.

[ARS101]

Wouldn't diverging from upstream turn this into a hostile fork?
Also not mentioning the development effort it needs.

I prefer crab to be just a simple fork, free of those trademark policy and strict CoC.
Basically a protest fork. Nothing more, nothing less.

[alkeryn]

@ARS101 would that even be allowed though?
Like if they change their license to force their bullshit on forks?

[trvswgnr]

@ARS101 can you please define "hostile fork"? thanks!

[ARS101]

@ARS101 would that even be allowed though? Like it they change their license to force their bullshit on forks?

The licensing of their code won't change. So no worries there.

[ARS101]

@ARS101 can you please define "hostile fork"? thanks!

Sorry @trvswgnr. Should have reworded it.

The definition of it is a fork that creates fragmentation in the community and confusion for the users which may not know which of variation of language to use.

Though fragmentation is bound to happen in a FOSS project.
And it is helpful in many cases like with neovim.

But in our case. And as title of this issue goes.
Introducing breaking changes here might completely split the efforts.
And slowing down development.

But I might be wrong here.
I haven't had experience developing a programming language.

[04l3x]

I think in technical terms it should not go outside the main language I think most would hate to have dialects.

[TCROC]

I propose that we add a new language under the CrabLang umbrella for breaking changes.

This will accomplish 3 goals:

1. Maintain compatibility with the Rust ecosystem that already exists and allow us to exist together.

2. We remain safe from the Rust Foundation.

3. We can create another language cause that's cool.

TL;DR

2 languages allows us to have our cake and eat it to :)

I actually suggested a new language over hear to fill a need :)

#6

Edit: typo
Edit: clarification

[trvswgnr]

I believe having our own experimental branch and sub-languages is completely acceptable. There won't be any confusion for anyone coming from Rust - the stable, compatible branch that includes the most recent upstream changes will be the only "recommended" branch.

[samualtnorman]

@ARS101 can you please define "hostile fork"? thanks!

Sorry @trvswgnr. Should have reworded it.

The definition of it is a fork that creates fragmentation in the community and confusion for the users which may not know which of variation of language to use.

Though fragmentation is bound to happen in a FOSS project.
And it is helpful in many cases like with neovim.

But in our case. And as title of this issue goes.
Introducing breaking changes here might completely split the efforts.
And slowing down development.

But I might be wrong here.
I haven't had experience developing a programming language.

in theory, forks and the like should split development but in practice that doesn't really happen.
forks don't normally pull people away from working on the original project (unless for good reason)
forks normally just act as a fallback for when someone would otherwise stop contributing

[samualtnorman]

yoooooooo