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]
