We will merge server based assemblies into their corresponding com.beamable assembly definitions.
If we start with the leaf nodes (aka, runtime), we should break the least number of assembly references.
someone should do this over the weekend, so that there is very very little chance of a merge conflict.
take a hard look at old PRs.... ECR? OTEL?
code-freeze com.beamable.server on Friday,
Saturday&Sunday, blast this PR into submission,
Monday, return to normal.
Also, we should do this at the end of the development, to minimize the patch 1.19.x sadness.
when a 1.0 user upgrades to 2.0, they need to manually go remove the com.beamable.server package before stuff works again.
However, we can continue to release a "shim" com.beamable.server package that is completely empty, so that
existing references don't "break", and
code isn't duplicated.
We need to have a date in mind, or a release version in mind for when the "shim" version goes away. Perhaps, whenever 3.0 is.
We will merge server based assemblies into their corresponding
com.beamable
assembly definitions. If we start with the leaf nodes (aka, runtime), we should break the least number of assembly references.someone should do this over the weekend, so that there is very very little chance of a merge conflict.
when a 1.0 user upgrades to 2.0, they need to manually go remove the
com.beamable.server
package before stuff works again. However, we can continue to release a "shim" com.beamable.server package that is completely empty, so thatWe need to have a date in mind, or a release version in mind for when the "shim" version goes away. Perhaps, whenever 3.0 is.