The way I interpret https://semver.org/, deprecated functionality should be
removed in a major release.
Users should be able to update to a new minor release without having to
worry that any of their code will break. It's certainly more convenient for
us to mark as deprecated and then remove whene
Using a different browser fixed the problem for me.
On Tue, Apr 2, 2019 at 5:53 PM Jinmei Liao wrote:
> I believe I used the Apache LDAP account, it's the same username anyway. I
> still keep getting this error:
> [image: Screen Shot 2019-04-02 at 5.52.14 PM.png]
>
> On Tue, Apr 2, 2019 at 3:12
> But this "hidden" feature, what is that? Is this something that we would
> like to support or is this something that would be replaced with our
> existing efforts in the ConfigurationService and Metrics area.
>
The old JMX agent [1] was superseded by the newer JMX manager [2] sometime
before geo
I'm eyeballing the ide.gradle file we have and am wondering if it is cruft
from many iterations of both Gradle and IntelliJ/Eclipse ago.
In my own IntelliJ workflow, I have always just asked IntelliJ to open the
gradle project via the build.gradle itself, and it's easy to import other
modules into
I tend to import into Intellij the way you have described. I've never
used ./gradlew
idea to configure.
-michael
On Wed, Apr 3, 2019 at 2:24 PM Patrick Rhomberg
wrote:
> I'm eyeballing the ide.gradle file we have and am wondering if it is cruft
> from many iterations of both Gradle and Intelli
I was under the impression that intellij's import actually used some of the
information in the idea{} blocks in the build. See
https://docs.gradle.org/current/userguide/idea_plugin.html.
But if the import works well without that extra configuration, I think we
should get rid of it.
-Dan
On Wed,
1) +1 YES. If we continue to *not* have at least one major release per
year, then I 100% support the removal of deprecated APIs and features in a
minor release such as 1.10. If we decide to have at least one major release
per year, then I'd be willing to revisit this and consider not allowing
remov
Would we announce that we aren't following semver anymore because bumping
the major version is somehow too expensive?
On Wed, Apr 3, 2019 at 3:29 PM Kirk Lund wrote:
> 1) +1 YES. If we continue to *not* have at least one major release per
> year, then I 100% support the removal of deprecated API
That’s your interpretation of semver. I interpret The API not to be broken
within a major as those that are still valid when the major is released despite
the availability of deprecated symbols from previous major. Just because I can
access symbols does not make it API. API is the combination of
