Skip to content
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

change version + documentation #36

Merged
merged 1 commit into from
Nov 22, 2022

Conversation

dhrubo-os
Copy link
Collaborator

Signed-off-by: Dhrubo Saha dhrubo@amazon.com

Description

[change version + documentation]

Issues Resolved

[List any issues this PR will resolve]

Check List

  • New functionality includes testing.
    • All tests pass
  • New functionality has been documented.
    • New functionality has javadoc added
  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Signed-off-by: Dhrubo Saha <dhrubo@amazon.com>
@dhrubo-os dhrubo-os merged commit c26709d into opensearch-project:main Nov 22, 2022
@dhrubo-os dhrubo-os deleted the 1.0.0b1 branch November 22, 2022 22:26
@@ -27,7 +27,7 @@
__title__ = "opensearch_py_ml"
__description__ = "Python Client and Toolkit for DataFrames, Big Data, Machine Learning and ETL in OpenSearch"
__url__ = "https://github.com/opensearch-project/opensearch-py-ml"
__version__ = "1.0.0-beta1"
__version__ = "1.0.0-b1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is the best practice to do so.
@dblock Any suggestion or input here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would release a 0.1.0, keep iterating on it until we're ready for a 1.0.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the build log, looks like setuptools (the library to build, install the package) auto normalizing this:

/private/var/folders/56/2tdnnvpn26n8f2jqp2ntxnyw0000gr/T/build-env-um0_7492/lib/python3.9/site-packages/setuptools/dist.py:530: UserWarning: Normalizing '1.0.0-beta1' to '1.0.0b1'

And this is happening due to PEP 440
So PEP 440 allows only five suffixes: a, b, rc, post and dev. b for beta.

To keep this consistent across everywhere I decided to keep 1.0.0b1

Copy link
Member

@dblock dblock Nov 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Semver (https://semver.org/) says -beta.1 is the correct label otherwise, but I personally prefer -beta1.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case 1.0.0-beta1 seems more appropriate as b1 might be confusing for the users

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dblock you meant to make the version 0.1.0-beta1?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe he meant either 0.1.0 or -beta1

Copy link
Collaborator Author

@dhrubo-os dhrubo-os Nov 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dblock @gaiksaya python is also following the similar approach : Python 3.5.0b1

In addition, if we just follow 0.1.0 approach, then in the long run let's say we already released 2.0.0 version. Now we want to release beta version of 3.0.0, in that case how exactly we can follow 0.1.0 approach?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should do what Python does.

Either way, please ignore me, @gaiksaya just asked for my opinion, but I am not the one to decide what we should do here.

On 3.0.0 beta, personaly I don't believe in beta releases, because they imply the project doesn't have mechanisms to release high quality software often. I'd prefer to confidently release 3.0, and if anyone wants to use an earlier build, not to bless a particular version as "beta".

gaiksaya pushed a commit to gaiksaya/opensearch-py-ml that referenced this pull request Feb 10, 2023
Signed-off-by: Dhrubo Saha <dhrubo@amazon.com>

Signed-off-by: Dhrubo Saha <dhrubo@amazon.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants