Date: Wed, 17 May 2023 13:16:24 -0500
On Wed, May 17, 2023 at 12:51 PM Ben Boeckel <ben.boeckel_at_[hidden]> wrote:
>
> On Wed, May 17, 2023 at 16:47:06 +0000, Charles-Henri Gros via SG15 wrote:
> > If we allow only closed intervals, which I really think we should, and
> > we really care about parsers that do not actually parse the JSON, then
> > I repeat my suggestion of an "a-b" syntax.
>
> Note that being too strict here means that if a tool releases with (say)
> version 1.2.3, everything using it needs to be updated to include that
> version in their compatibility range. Imagine if you had to wait for a
> new CMake release for any compiler release for them to claim to support
> each other. If we thought the C++ ecosystem was deadlocked and hard to
> work with today, that sounds even more daunting to me.
There's also the case of allowing for DRs in publication. It's DRs
that are likely to bump the minor and/or patch numbers. And, yeah, it
could be challenging for interop if such DRs mean a bunch of changes
for all kinds of tools. But I guess this all depends on how we use the
versions. Which I just don't feel we can know at this point. And will
need some actual experience before nailing anything restrictive.
> > If we do only have monotonic increases, then I'm not completely sure
> > I'm on board with the a.b.c versioning scheme. The "small change" vs
> > "large change" distinction doesn't seem worth encoding in the version
> > number if I have to claim exact support anyway.
>
> I don't think anyone can guarantee that new releases will keep support
> for anything in older versions. The component-wise versioning
> communicates whether one can expect to update without issues. I'd be in
> favor of just importing SemVer-like semantics[1] (and its comparison
> operators) with guidance like:
>
> - patch-level changes should be compatible with any other
> otherwise-similar version numbered release ("bug fixes; I'll specify a
> minimum patch level if one affects me")
> - minor-level changes should be compatible with any same-major,
> larger-minor release ("new features added, but I don't need them")
> - major-level changes mean "please retest your compatibility as we may
> have removed functionality you were relying on" and will, generally,
> require ecosystem syncups to claim compatibility
I would also like to operate on a semver model for this. Which is why
I refer to it in the paper. But as I said above.. Not sure what we
will need vs. what we want at this point.
> [1] Importing SemVer itself into ISO is probably a whole different beast
> as I suspect it is outside of the ISO "allowed to reference" list.
And right, just referring to SmeVer in the IS is not possible. As it's
not a standard in any real form. So we can't even evaluate the part
about it being one of the liason organizations. Which unfortunately is
going to be a recurring aspect of things in the EcoIS :-(
>
> On Wed, May 17, 2023 at 16:47:06 +0000, Charles-Henri Gros via SG15 wrote:
> > If we allow only closed intervals, which I really think we should, and
> > we really care about parsers that do not actually parse the JSON, then
> > I repeat my suggestion of an "a-b" syntax.
>
> Note that being too strict here means that if a tool releases with (say)
> version 1.2.3, everything using it needs to be updated to include that
> version in their compatibility range. Imagine if you had to wait for a
> new CMake release for any compiler release for them to claim to support
> each other. If we thought the C++ ecosystem was deadlocked and hard to
> work with today, that sounds even more daunting to me.
There's also the case of allowing for DRs in publication. It's DRs
that are likely to bump the minor and/or patch numbers. And, yeah, it
could be challenging for interop if such DRs mean a bunch of changes
for all kinds of tools. But I guess this all depends on how we use the
versions. Which I just don't feel we can know at this point. And will
need some actual experience before nailing anything restrictive.
> > If we do only have monotonic increases, then I'm not completely sure
> > I'm on board with the a.b.c versioning scheme. The "small change" vs
> > "large change" distinction doesn't seem worth encoding in the version
> > number if I have to claim exact support anyway.
>
> I don't think anyone can guarantee that new releases will keep support
> for anything in older versions. The component-wise versioning
> communicates whether one can expect to update without issues. I'd be in
> favor of just importing SemVer-like semantics[1] (and its comparison
> operators) with guidance like:
>
> - patch-level changes should be compatible with any other
> otherwise-similar version numbered release ("bug fixes; I'll specify a
> minimum patch level if one affects me")
> - minor-level changes should be compatible with any same-major,
> larger-minor release ("new features added, but I don't need them")
> - major-level changes mean "please retest your compatibility as we may
> have removed functionality you were relying on" and will, generally,
> require ecosystem syncups to claim compatibility
I would also like to operate on a semver model for this. Which is why
I refer to it in the paper. But as I said above.. Not sure what we
will need vs. what we want at this point.
> [1] Importing SemVer itself into ISO is probably a whole different beast
> as I suspect it is outside of the ISO "allowed to reference" list.
And right, just referring to SmeVer in the IS is not possible. As it's
not a standard in any real form. So we can't even evaluate the part
about it being one of the liason organizations. Which unfortunately is
going to be a recurring aspect of things in the EcoIS :-(
-- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
Received on 2023-05-17 18:16:39