adam-christian-software commented on code in PR #39: URL: https://github.com/apache/polaris-tools/pull/39#discussion_r2527905984
########## mcp-server/pyproject.toml: ########## @@ -0,0 +1,48 @@ +# +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +# + +[project] +name = "polaris-mcp" +version = "0.9.0" Review Comment: So, I think there are two things here: 1. The "how" we ship. 2. The "versioning" heuristics we should use. For #1, @flyrain has filed an Issue ( https://github.com/apache/polaris-tools/issues/46 ) to investigate the packaging and publishing. Right now, I don't believe that we need to think about this since we can largely borrow the principles that we use for the Python CLI when we have completed that work. For #2, I have assumed that we will use the typical semantic versioning approach (https://semver.org/). While that helps us determine when we do breaking changes and when we don't, it does not provide the entire guidance. SemVer states: > - Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. > - Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes. For this particular project, I would say that it makes sense for us to release first with 0.9.0 because this work is still very much in a prototype phase. We have several Git issues to tackle to firm up the solution. We should get those done after this PR and a lot of those items should be done before the first release. This begs the question: When do we go from 0.X.0 to 1.0.0? For me, I would say a few things should happen: 1. We have one user who has used this work and given feedback. 2. We should not have any critical issues. 3. We should have good-enough unit & IT testing. 4. As this is a client of our Polaris server, we should nail down our compatibility story. 5. We should do a quick audit of any security issues. 6. We should have user-facing documentation on the Polaris Hugo site. 7. We should have all of the operational readiness items done - deployment processes, monitoring/observability, & upgrades/rollback processes. Until we nail those 7 things, I wouldn't put this as a 1.0.0 project. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
