I would be very upset and surprised as a user or developer if Geode never
has any major releases.
Using semver as the main argument to not remove a feature that has been
deprecated for 7 years is silly.
Let’s have a major release! 2.0 by summer.
On Fri, Apr 5, 2019 at 8:38 AM Jacob Barrett wrot
I figured I’d take this discussion up with the experts and founding fathers. ;)
https://github.com/semver/semver/issues/508
-jake
> On Apr 4, 2019, at 8:23 AM, Anthony Baker wrote:
>
> Let’s separate the discussion into these parts:
>
> - What does SemVer say and how do we apply it
> - When
I believe that putting off a major release such as 2.0 for several years is
an artificial way to prevent ever removing anything that is deprecated.
Following SemVer should be part of a reasonable software release cycle, and
a reasonable software release cycle should involve periodic major releases
Let’s separate the discussion into these parts:
- What does SemVer say and how do we apply it
- When should we remove deprecated code
- Should we remove the admin source code entirely
1) SemVer
Straight from the spec:
> Major version X (X.y.z | X > 0) MUST be incremented if any backwards
> in
I'm not sure if I'm interpreting various parts of this conversation
correctly, but it seems that one view being assumed is that the actual
removal of deprecated APIs *must* happen in the first version of a major
release bump. i.e. for this discussion that would be *2.0.0*. I don't
believe this is a
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
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
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
> 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
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
+1 since it's been deprecated pre geode 1.0, and I have no idea what its
purpose.
On Tue, Apr 2, 2019 at 5:20 PM Jacob Barrett wrote:
>
>
> > On Apr 2, 2019, at 5:04 PM, Dan Smith wrote:
> >
> > I think the best course of action is probably to remove it entirely.
> > However, this does bring up
> On Apr 2, 2019, at 5:04 PM, Dan Smith wrote:
>
> I think the best course of action is probably to remove it entirely.
> However, this does bring up a couple of questions:
>
> 1) Is it ok in general to remove deprecated API in a non X.0 release (eg
> geode 1.10 instead of geode 2.0)?
I thin
+1 on removing the JMXManager stuff for Geode 2.0 release.
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.
On 4/2/19 17:04, Dan Smith wr
13 matches
Mail list logo
