You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by GitBox <gi...@apache.org> on 2022/05/07 14:21:34 UTC

[GitHub] [arrow-datafusion] andygrove opened a new issue, #2475: Should we switch to calendar versioning?

andygrove opened a new issue, #2475:
URL: https://github.com/apache/arrow-datafusion/issues/2475

   **Is your feature request related to a problem or challenge? Please describe what you are trying to do.**
   For historical reasons, we are not able to release using pre-1.0.0 version numbers and because we are following [SemVer](https://semver.org/) we have a rapidly increasing major version number which can create misconceptions about the maturity of the software.
   
   An alternative approach would be to switch to [CalVer](https://calver.org/) (calendar versioning) instead. Ubuntu is a good example of a project that uses CalVer, with version 22.04 released in April 2022. NVIDIA has recently switched to CalVer for some of its projects, including [cuDF](https://github.com/rapidsai/cudf).
   
   With calendar versioning, releases get better over time.
   
   For full details, see https://calver.org/ and in particular the section ["When to use CalVer"](https://calver.org/#when-to-use-calver), which I think describes our projects quite well.
   
    
   
   
   
   
   
   
   **Describe the solution you'd like**
   A clear and concise description of what you want to happen.
   
   **Describe alternatives you've considered**
   A clear and concise description of any alternative solutions or features you've considered.
   
   **Additional context**
   Add any other context or screenshots about the feature request here.
   


-- 
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: github-unsubscribe@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [arrow-datafusion] andygrove commented on issue #2475: Should we switch to calendar versioning?

Posted by GitBox <gi...@apache.org>.
andygrove commented on issue #2475:
URL: https://github.com/apache/arrow-datafusion/issues/2475#issuecomment-1121474385

   A question came up about how this would work with SemVer since `22.5` would normally be considered a safe upgrade from `22.4` but this is not the case with CalVer.
   
   We need to pick a pattern to use but let's assume `YY.MM.patch` for this discussion and let's also assume we have a major release of `22.4.0`. Users would need to use [tilde requirements](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#tilde-requirements) to depend on this release:
   
   ``` toml
   datafusion = "~22.4.0"
   ```
   
   This would let Cargo choose any version `>= 22.4.0 < 22.5.0` so would allow us to release patches to the `22.4` release. One downside here though is that we would then be restricted to one major (breaking change) release per month.


-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [arrow-datafusion] andygrove closed issue #2475: Should we switch to calendar versioning?

Posted by GitBox <gi...@apache.org>.
andygrove closed issue #2475: Should we switch to calendar versioning?
URL: https://github.com/apache/arrow-datafusion/issues/2475


-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [arrow-datafusion] andygrove commented on issue #2475: Should we switch to calendar versioning?

Posted by GitBox <gi...@apache.org>.
andygrove commented on issue #2475:
URL: https://github.com/apache/arrow-datafusion/issues/2475#issuecomment-1120220290

   Note that if we start releasing monthly using our current versioning scheme we will be at version 22.x by July of next year anyway.


-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [arrow-datafusion] alamb commented on issue #2475: Should we switch to calendar versioning?

Posted by GitBox <gi...@apache.org>.
alamb commented on issue #2475:
URL: https://github.com/apache/arrow-datafusion/issues/2475#issuecomment-1122347169

   > Has there been feedback that large major version numbers are a problem? I'd have thought it was just a number...
   
   I would also like to hear from anyone who feels like the major version numbers are an issue causing confusion or concern with DataFusion.
   
   Historically, I think the switch to calendar versioning is typically driven by companies where the determination of "what constitutes enough of a feature set to warrant a new major version" is challenging (e.g. this post by [cockroach labs](https://www.cockroachlabs.com/blog/calendar-versioning/))
   
   DataFusion doesn't have this challenge from my perspective: whenever we release a new version we bump the major version. Rather than it being a marketing motion, the version bump seems is just something mechanical. Also, I think with the rise of things like semver and Dependabot the human interpretation of major versions will become even less important in projects going forward


-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [arrow-datafusion] tustvold commented on issue #2475: Should we switch to calendar versioning?

Posted by GitBox <gi...@apache.org>.
tustvold commented on issue #2475:
URL: https://github.com/apache/arrow-datafusion/issues/2475#issuecomment-1122030609

   Are there examples of other Rust projects that do this, whilst technically possible I worry it will create confusion...
   
   Has there been feedback that large major version numbers are a problem? I'd have thought it was just a number...
   
   Perhaps the real fix is to make breaking changes less frequently...


-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


[GitHub] [arrow-datafusion] andygrove commented on issue #2475: Should we switch to calendar versioning?

Posted by GitBox <gi...@apache.org>.
andygrove commented on issue #2475:
URL: https://github.com/apache/arrow-datafusion/issues/2475#issuecomment-1122846282

   Thanks for the feedback @tustvold and @alamb. I have not seen any notable Rust projects use CalVer, so I agree that this could be confusing. I have definitely heard people express surprise at the rapidly increasing major version but perhaps this is because it is not the norm rather than being based on specific technical concerns.
   
   Let's leave this issue open a little longer to see if there are other opinions on this, and if not, I will close this.


-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org