-
Notifications
You must be signed in to change notification settings - Fork 711
Release for 1.0.0rc1 #1601
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release for 1.0.0rc1 #1601
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per the comment in the code, I would suggest we release a 0.18b0 of the packages that are not 1.0.0rc1 and have those packages rely on 1.0.0rc1 where possible
@@ -12,4 +12,4 @@ | |||
# See the License for the specific language governing permissions and | |||
# limitations under the License. | |||
|
|||
__version__ = "0.18.dev0" | |||
__version__ = "0.17.b0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will cause a failure during the publishing step of the build to pypi, i vote to release a new version that depends on the 1.0.0 release
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed build.sh
to only build the packages we want and spit them into dist/*
. Thus the build script in github actions will only pick up the ones we want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Plus, releasing a new version 0.18b won't work because it cannot depend on 1.0.0rc1
since 1.0.0rc1
wouldn't exist yet.
@@ -16,7 +16,7 @@ DISTDIR=dist | |||
mkdir -p $DISTDIR | |||
rm -rf $DISTDIR/* | |||
|
|||
for d in opentelemetry-api/ opentelemetry-sdk/ opentelemetry-instrumentation/ opentelemetry-proto/ opentelemetry-distro/ exporter/*/ shim/*/ propagator/*/; do | |||
for d in opentelemetry-api/ opentelemetry-sdk/ opentelemetry-proto/ exporter/opentelemetry-exporter-jaeger/ exporter/opentelemetry-exporter-otlp/ exporter/opentelemetry-exporter-zipkin/ propagator/*/; do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any reason not to release a new version even for the packages that arent at 1.0.0? this would allow users to test the 1.0.0rc from all the packages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you mean why can't we release both 1.0.0rc1
AND 0.18b
at the same time, it would look strange since this release will be tagged as 1.0.0rc1
. I will be doing a release for 0.18b
shortly after this one that will depend on 1.0.0rc1
that will already be released.
Will only be releasing:
opentelemetry-api
opentelemetry-sdk
opentelemetry-exporter-jaeger
opentelemetry-exporter-otlp
opentelemetry-exporter-zipkin
opentelemetry-proto
opentelemetry-propagator-b3
opentelemetry-propagator-jaeger
The build script (
build.sh
) has been modified to only create dists for these above packages.Since it is only rc1, we will not be adding the
Development Status :: 5 - Production/Stable
classifier as of yet.The packages that are not rcing will be kept at
0.17b0
and a separate release will be cut for those.