Remove @Beta from RangeSet and RangeMap

[tyomka]

Range has been marked with @Beta since 10.0 (September 28, 2011).
RangeMap, RangeSet and their implementations since 14.0 (February 25, 2013).

I would like to propose to remove the @Beta annotation.

[kevinb9n]

(The only part of Range that's still beta is asSet().) I feel like we should be able to take care of these in the next batch of debeta-ings.

[tyomka]

@cpovirk
I've mistakenly assumed that Range is annotated with @Beta. It is not.
Still the issue context is still relevant for RangeMap and RangeSet.

[shashvat-kedia]

@tyomka Can I work on this?

[gskaplan]

Is there any update on this?

[prissky]

Is there any news?

[ggarcia-te]

Any news about this?

[tyomka]

Any news about this?

I'm kinda waiting for someone from the Guava team to validate my pull request. Is there anything i can do?

[julianhyde]

+1 to remove @Beta. Apache Calcite, as of release 1.26, relies on RangeSet (and it appears in the Calcite's public API in one place, class Sarg). We are prepared to shade, and break our API if it comes to that, because RangeSet is the perfect library for what we need. Some certainty would be appreciated. If RangeSet is going away we can make other plans.

[zabetak]

I can see that the issue is open for more than a year. Is the Guava team at least considering this request?

[mwunderlich]

Any updates on removing @beta for RangeMap (also applies to TreeRangeMap)?

[runnable-thread]

Any updates on removing @beta for RangeMap (also applies to TreeRangeMap)?

[kluever]

This is now fixed.

[taomoh]

This is now fixed.

@kluever Do you know which version this fix is going to be released in?
Latest version 31.1-jre doesn't have it

[kluever]

It'll be in the next version of Guava --- I think @cpovirk was planning on cutting a release in the next few weeks?

[cpovirk]

Yes, maybe the end of next week if all goes well. If not, I'd hope the week after.

[julianhyde]

@cpovirk, It's helpful if you can state the release number when it will be fixed. Because many of us dependent issues and we want to write 'Fixed in Guava 32.0' and move on.

[cpovirk]

It will be 32.0.0. (Even though it will be a major-version bump, the release will probably not contain any breaking changes to Guava itself: It will just contain a small breaking change to the much less used guava-testlib, and we keep the version numbers of the two in sync.)