Consider supporting version ranges in evolution page search fragment

[dempseyatgithub]

Currently, on the evolution dashboard page, search queries as well as all filters generate and accept a fragment in the URL that defines the search.

For example searching for proposals with the word ’regex’ that are Implemented:
http://www.swift.org/swift-evolution/#?status=implemented&search=regex

This is also true of the Swift version filters for implemented proposals:
http://www.swift.org/swift-evolution/#?version=5.3,5.4,5.5

The comma-separated list of versions can get cumbersome and long, especially when trying to express a range of releases.

For example a link that will show all proposals with an upcoming feature flag that is valid in Swift 5.8 would be:

https://www.swift.org/swift-evolution/#?version=5,5.1,5.2,5.3,5.4,5.5,5.5.2,5.6,5.7,5.8&upcoming=true

It would be useful if the version could accept a range of versions in addition to individual versions.
https://www.swift.org/swift-evolution/#?version=5.1-5.8&upcoming=true

Multiple individual versions and version ranges can be used and combined separated by a comma:
https://www.swift.org/swift-evolution/#?version=2.2-3,4.2,5.1-5.8&upcoming=true

I have an implementation of this but wanted to open this issue to discuss before opening a PR.

[dempseyatgithub]

@kaishin

[natikgadzhi]

I just stumbled on this when I was working on #369.

There are a few blog articles that link to the old github pages Swift Evolution site apple.github.io/swift-evolution, and that one supported querying by Swift version: (https://apple.github.io/swift-evolution/#?version=5.7.

6 results - 4 files

_posts/2017-01-18-swift-evolution-status-page.md:
  7  
  8  
  9: We're pleased to announce the release of the new [Swift Evolution](https://apple.github.io/swift-evolution/) status page as a one-stop destination for information about proposed changes to Swift.
  9  
  10  

_posts/2022-07-01-swift-language-updates-from-wwdc22.md:
  12  
  13: Swift has evolved significantly during the past year, and we've seen two large updates to the language. [Swift 5.6](https://apple.github.io/swift-evolution/#?version=5.6) was released in March 2022 and introduced major improvements to the type system, concurrency model and Swift ecosystem. It laid the groundwork for further updates in [Swift 5.7](https://apple.github.io/swift-evolution/#?version=5.7), which is included in [beta versions of Xcode 14](https://developer.apple.com/download/applications/) and available on the [Swift.org downloads page](/download/#swift-57-development).
  14  

_posts/2022-09-12-swift-5.7-released.md:
   76  
   77: The following [Swift Evolution](https://github.com/apple/swift-evolution) proposals for SwiftPM were accepted and [implemented in Swift 5.7](https://apple.github.io/swift-evolution/#?version=5.7):
   78  

  120  
  121: The following language, standard library, and Swift Package Manager proposals were accepted through the [Swift Evolution](https://github.com/apple/swift-evolution) process and [implemented in Swift 5.7](https://apple.github.io/swift-evolution/#?version=5.7).
  122  

_posts/2023-03-30-swift-5.8-released.md:
  121  
  122: The following language, standard library, and Swift Package Manager proposals were accepted through the [Swift Evolution](https://github.com/apple/swift-evolution) process and [implemented in Swift 5.8](https://apple.github.io/swift-evolution/#?version=5.8).
  123  

That's no longer the case. It redirects to the http://www.swift.org/swift-evolution page, but drops the query parameter.

To fix the broken links, I thought I can just link to http://www.swift.org/swift-evolution instead, but alas, since it does not have the version filter, that would not land users on what they want to see (i.e. proposals accepted and implemented in a specific version of Swift).

I'm not actively working in this. But, once this is solved, we can clean out a few of those old links.

[dempseyatgithub]

The version filter query string is present at http://www.swift.org/swift-evolution.

For example:
https://www.swift.org/swift-evolution/#?version=5.9

This issue is to consider enhancing the existing query string functionality to include handling ranges of versions.

You should be able to update links pointing to the previous evolution page location to the new URL, including the query strings.

If one or more query strings from an old evolution URL doesn’t work, please file a separate issue.

[kaishin]

@dempseyatgithub Range support in the URL query is definitely a nice-to-have. Are there any links on the site that would be shortened if this gets implemented? I am fine with moving forward with it either way, just curious if there are any immediate applications.

[dempseyatgithub]

@kaishin A use case I was thinking about was being able to have a URL that would filter to all the upcoming feature flags of a given major version. So, it’s more a URL that is not currently expressible.

But a plain range doesn’t solve this problem as nicely as it could, since the URL would constantly need to be updated to include the end of the range.

Thinking about his further, I think maybe instead of adding support for a range there are two things we might consider adding:

1. Add a setting such as #?version=currentMajor or #?version=current that specifies the entire range of versions with the current major version number.

This would allow for an ‘evergreen’ URL to link to the UFFs that are valid in the current major version:

https://www.swift.org/swift-evolution/#?version=current&upcoming=true

I like the compactness of current although it is less precise than currentMajor.

Maybe allCurrent would be a good balance between conciseness and precision.

2. An alternate would be to add the ability to handle something like #?version=5*, a major version followed by a wildcard character. This would be interpreted as "all versions of Swift 5”.

The more I think about it, the more I think that option 1 (#?version=current), is the solution that would best address the main use case I was looking to solve.

With option 2, any link that tried to lead developers to the currently valid list of upcoming feature flags would need to be updated with every major release.

[kaishin]

@dempseyatgithub I like the idea of supporting current instead of ranges.

The more I think about it, the more I think that option 1 (#?version=current), is the solution that would best address the main use case I was looking to solve.

That would be my vote as well. Let's get green light on this from the workgroup before we proceed!

[dempseyatgithub]

That would be my vote as well. Let's get green light on this from the workgroup before we proceed!

Yes. It will probably be over the holidays, but I'll flesh this out into more specific proposal.