Replies: 3 comments 1 reply
-
|
I'm personally in favour of the current approach. Having incredibly noisy warnings should be almost the same as the code not working. The only issue I see is if people migrate directly from 2.x -> 3.1 and miss the warnings visible in 3.0. I also thing semver is a great, well-understood versioning mechanism by which we communicate clearly to users the nature of a new release. Maybe it's acceptable only to make deprecation like this only in a x.0 to x.1 release. I would also be happy with doing a minor 2.x release with deprecation warnings and removing all deprecated code in 3.0. The disadvantage of this is that it would make maintaining the 2.x branch more complex as the warnings would really be pretty annoying to people using 2.x - if we had to backport security fixes, it would make adoption more annoying. I'd be okay with this if warnings were non-noisy by default and we tell users: "In order to migrate from Rack 2 to Rack 3, enable verbose warnings in Rack 2 to know about things which are broken in Rack 3". |
Beta Was this translation helpful? Give feedback.
-
|
I'm ok with the current approach. And I think it lowers the burden on the maintainers, given we don't need to keep a lot of deprecated code around just to avoid releasing a major version. But, we need to document we are following a shifted-semver somehow, maybe in the release blog post, README, etc. People are used to now upgrade Rails from 5.2 to 7.0 without going through each minor version between. Same thing with Ruby. I don't see much problem if we communicate this properly. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the current approach of deprecating in 3.0 and removing in 3.1. I don't think this requires any documentation of our approach. Rack has never followed semantic versioning, it changes behavior in minor versions and even tiny versions. However, if someone wants to write such documentation, I don't have a problem merging it. |
Beta Was this translation helpful? Give feedback.
-
|
From your point of view, is 3.0.x an in-between 2.x and 3.x release - i.e. compatible between both worlds? Do you imagine some users would pin to Rack Just interested in your take on how end users are supposed to consume these warnings and how we would expect them to use the 3.0 release. What's your expected time frame for a 3.1 release? 1 day? 1 month? 1 year? |
Beta Was this translation helpful? Give feedback.
-
We have a unique opportunity with Rack 3 to deal with code we want to deprecate.
Just to contextualise this a little bit:
Given the importance of Rack, I think this slow release cycle is reasonable to me - stability and compatibility is important. That being said, the release of a major version is a unique opportunity in the timeline to do something drastic like cutting existing code/functionality and I think we should (and are) taking advantage of that to clean up some of the loose ends in the code base.
Our current strategy which has been discussed and to a certain extent agreed on between myself and @jeremyevans in PRs where it was relevant, was to introduce visible warnings for deprecations in Rack 3.0 which would then be removed along with the relevant code in Rack 3.1. However, it feels like we should clarify whether this is what we want to do generally.
I want to make sure we are doing the right thing here. As far as I see it, there are a set of trade offs.
Loud warnings in 3.0 for deprecated functionality and removal of functionality in 3.1.
This is our current strategy. This strategy does not follow semver but is (AFAIK) the same as Rails.
This allows us to give people who upgrade to Rack 3.0 clear warnings about functionality that will be removed later in 3.x. This also sets the expectations that we can add deprecation warnings and remove functionality in a subsequent minor release.
In line with this, and also compatible with semver, this would also mean we could create a final 2.x release (minor version bump) to backport these warnings and remove in 3.0 release.
Loud warnings in 3.0 for deprecated functionality and removal in 4.0.
This is a proposed strategy. This strategy follows semver.
This remains the most compatible approach. If we decided on this approach, I would personally like to see us do a minor release on the 2.x branch with warnings and remove functionality in 3.0 to make a clean break.
The alternative is maintaining these warnings and deprecated functionality for ~6 years OR doing a rapid release of Rack 4 (undesirable IMHO).
Beta Was this translation helpful? Give feedback.
All reactions