Hi All, We can start working in 2 branches as the idea is to migrate to java 11 too, we need to duplicate everything anyway. I really don't want to be the one that has to go to our external plugin developers (there are multiple parties that already have plugins) and tell them their plugins can/will break every month because of a new release. This would also block users from getting new features in our codebase because they would have to wait for the external parties to update their plugin.
Java 8 is EOL in march 2022 so 2.0 will be released in the next 6 months. Cheers, Hans On Wed, 29 Sept 2021 at 15:48, Sergio Ramazzina (SERASOFT) < [email protected]> wrote: > Hi all, > > I personally agree with Nicholas by saying that it would be better to > postpone the need to be rigorous for version 2. > > I think we can consider version 1 as a sort of transition version, give > another big push toward cleaning, semplification and making fixes and > reach the goal of having a really solid version 2 from all the points of > view. Now it's too early, there are too many things that remains to be > done in my opinion. > > Best > > Sergio > > Il 28/09/2021 20:56, Nicolas ADMENT ha scritto: > > Hi All, > > > > Hop is an ecosystem of plugins and for this ecosystem to develop in the > > future, we must provide simple and efficient APIs. > > > > I think it would be better to inform today that the Java APIs are not yet > > stable and that these APIs can still change up to version 2. > > And so take advantage of this time to do more code cleanup. > > After version 2 it will be necessary to be much more rigorous on these > > changes, > > but for the moment it seems too early to me. > > > > But that's just my point of view. > > > > Cheers, > > Nico > > > > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > Garanti > > sans virus. www.avast.com > > < > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > Le lun. 27 sept. 2021 à 09:16, Hans Van Akelyen < > [email protected]> > > a écrit : > > > >> Hi All, > >> > >> I agree that we have to continue our code cleanup and optimization, but > >> should not add breaking changes in our current major version. > >> The best approach would be to start creating a technical debt or maybe a > >> "migration guide" for our external developers. > >> Once there is a 2.0 branch and there are builds they can start creating > a > >> 2.0 compatible version. > >> All Major changes or updates to this guide/debt page should also be > >> announced here on the developers list so they know their plugins could > be > >> impacted. > >> > >> Cheers, > >> Hans > >> > >> On Fri, 24 Sept 2021 at 11:03, Matt Casters <[email protected] > >> .invalid> > >> wrote: > >> > >>> Dear Hoppers, > >>> > >>> Nicolas just filed a great PR for an API simplification. I really like > >> it > >>> but at the same time we already have a number of plugins external to > the > >>> project and we probably don't want to break all that code. > >>> Unfortunately this PR is not the last thing we'd want to change with > the > >>> upcoming Java 11 (and beyond) code migration is still ahead of us. So > >> how > >>> do we structurally tackle this? > >>> > >>> Creating a task in JIRA is one thing, perhaps we can document this as > >> well > >>> to make it easier to later migrate plugins to version 2 (and beyond)? > >>> Should we start a "technical debt" page in the developer documentation? > >>> > >>> Cheers, > >>> Matt > >>> -- > >>> Neo4j Chief Solutions Architect > >>> *✉ *[email protected] > >>> >
