We have a few outstanding PRs that it would be great to align with main. These were intended to unblock us on downstream clients, but maintaining separate branches longterm isn't great hygeine or open source and is a bit of a maintenance burden.
The specific features are:
- download images (not just copy which is live on
main)
- precompile option
- Deck GL lighting pass through
I believe we can just close the download images one in favor of newer tooling.
As far as the others, we should decide the best course of action. Here's the paths we can take:
Continue maintaining the current branches
Pros
Cons
Fork this repo specifically for downstream client
Pros
- More flexibility in terms of added features for specific use case
- No need to use generic/public options where specific/private ones are better
Cons
- Same maintenance burden as separate branch, just different merging process
Clean up implementation and bring features into main
Pros
- No separate maintenance tasks, one source of truth
Cons
- Features may be confusing or unhelpful to general users
- Limits fast iteration
@almccon @ebrelsford what do you both think?
Personally, I think we should officially fork the repo as this is a recurring theme (in terms of adding features) rather than a couple of one offs. It still gives us the option to reincorporate features from the fork to the open source repo later if we choose. We already have an undocumented customJs option on main here as a backdoor to certain setups and I think we should avoid having more features like this. I also think we should remove that feature from main here in the open source version due to some nuance in when it's triggered, but that's a separate ticket.
We have a few outstanding PRs that it would be great to align with
main. These were intended to unblock us on downstream clients, but maintaining separate branches longterm isn't great hygeine or open source and is a bit of a maintenance burden.The specific features are:
main)I believe we can just close the download images one in favor of newer tooling.
As far as the others, we should decide the best course of action. Here's the paths we can take:
Continue maintaining the current branches
Pros
Cons
Fork this repo specifically for downstream client
Pros
Cons
Clean up implementation and bring features into
mainPros
Cons
@almccon @ebrelsford what do you both think?
Personally, I think we should officially fork the repo as this is a recurring theme (in terms of adding features) rather than a couple of one offs. It still gives us the option to reincorporate features from the fork to the open source repo later if we choose. We already have an undocumented
customJsoption onmainhere as a backdoor to certain setups and I think we should avoid having more features like this. I also think we should remove that feature frommainhere in the open source version due to some nuance in when it's triggered, but that's a separate ticket.