Roadmap Suggestions for 2.0.0

[EarthCitizen]

@pivovarit

For the near long term, I think the following would be (some of the) good goals (IMO) for a 2.0.0 release:

• Minimum JDK 17
• Take advantage of sealed classes in Java 17. Make Try and Option (and possibly others) sealed classes.
• Take advantage of records. Make Try and Option implementations records. This could pave the way in the future of parameter matching on Some, Success, etc.

Others should feel free to chime in and add their thoughts on a roadmap to 2.0.0.

[pivovarit]

Personally, I would release v0.10.4 as v1.0.0 after a few rounds of bug fixing and improvements to seal the deal and signal that this is feature-complete. However, the next major release should definitely be JDK17-based if not JDK21.

However, I'm afraid you pinged the wrong person

[danieldietrich]

Hey @EarthCitizen, thanks! Jumping on an actual long term release makes sense, that was also on my mind.

@pivovarit creating a 1.0.0 based on an actual version is a good suggestion and an important signal to the community.

I will elaborate on the roadmap along with a plan to have more project sponsors.

Regarding sponsorship, I will need to find companies and persons who are relying on Vavr in a long term manner.

[EarthCitizen]

@pivovarit Sorry. Based on your comments on another issue, I interpreted that as you would be one of the main people taking over :-)

After the current code base is released as 1.0.0, looking toward what's after that, I think it is too early to have a minimum JDK of 21. Spring Boot, for example, just switched to JDK 17 as the minimum.

[pertl]

Please, please with much sugar on the top ... release 1.0.0

Using plain java even in java-21 with it's weak abstraction of functional patterns makes me cringe (don't even mention Optional[T]) .

I used vavr for many projects, but sadly the 0.10.4 version since having an -alpha in the version would be a huge downer in a code review. v1 is long overdue and would make acceptance in an project much easier. You can always release v1.0.1 if anything is missing. Nobody would be sad. The -alpha version has been out so long I would be confident that it's fine and could be released as -final.

Having java17 as an prerequisite would be an candidate for v1.1.x or v2.0.x imho.

And yes, j21 is too early.

[ezoerner]

Suggest triaging the open issues making sure they are labeled correctly as bug or not, and label the ones that should be fixed for a 1.0.0 release. I may be able to help fix bugs that are prioritized. It would be helpful to have at least one final release that works with JDK 8 since there are still a lot of projects that are stuck on that.

[EarthCitizen]

I agree with @pivovarit and @pertl and @ezoerner. Current code base should be released as 1.0.0, and my original suggestion of going to JDK 17 should be 2.0.0. My original thought was that 1.0.0 would be the new start, but it makes a lot of sense to release what exists as 1.0.0.

[EarthCitizen]

Renamed this issue to suggestions for 2.0.0.

[pertl]

I would not even bother with current open issues but just release v1.0.0 right now and release bug fixes in subsequent v1.0.x releases. The -alpha has been tested for so long it really can't be that wild.

The signal from having a final release that it management proof (they don't trust any -alpha or -beta) will make quite a difference. No matter how much "innovation" Oracle puts into current java - the functional / immutable side is still a desaster imho

[pertl]

And I would just release more often to counteract the impression the project is dead. That's what you might think if you look at the release cycles. This will make it easier to find people investing in the project. Nobody wants to sit on a dead horse :-)

[pertl]

v1.0.0 would probably be the right time to remove deprecations, e.g. "class $"