Tag NamedTuples v3.0.3 [https://github.com/blackrock/NamedTuples.jl]

[mdcfrancis]

Diff vs v3.0.2: JuliaData/NamedTuples.jl@4d0571e...65c5caa

[mdcfrancis]

Added the v3.0.4 tag as well to change set

[tkelman]

Looks like this would cause some problems downstream with IterableTables - we may want to upper-bound the existing versions there, if return types changed in a breaking way

[shashi]

Making the upper bound change in this repository would suffice for now, right?

Possibly something to automate in the future.

[tkelman]

yes, in-place in the metadata copies of the requires files. don't touch the existing sha1 files. can be a bit complicated, but we should add some helper scripts or functions to handle simple cases, yes

[davidanthoff]

I'm looking into the breaking change now, but minimally the breaking change should not be handled via a patch version increase, right?

[davidanthoff]

Alright, I looked into this now. The breaking change is fine for IterableTables and Query, in fact the new behavior makes things slightly easier on my end.

But versioning wise that change really should be v4.0.0, it is after all a breaking API change. So I think v3.0.3 should be tagged as is right now. But what is being proposed as v3.0.4 currently should instead be v4.0.0.

I'll add upper bounds on the currently released IterableTables and Query versions that exclude v4.0.0, and then I'll tag a new release of IterableTables and Query that works with NamedTuples v4.0.0.

[davidanthoff]

Once #9567 is tagged it should be safe to tag the breaking change in NamedTuples as v4.0.0.

[shashi]

It seems like the breakage was caused by use of something not exported (NamedTuples.make_tuple - used to return a symbol, now returns the type itself).

As far as users who don't care about the guts of the package are concerned, this release adds a method to Base.isless and fixes problems in serializing NamedTuples. It's not a breaking release.

Can we merge this?

@mdcfrancis do you know about https://github.com/attobot/attobot ? It makes releasing / re-tagging a breeze. Thanks for your effort!

[davidanthoff]

Well, it is breaking both IterableTables and Query, two of the most heavy users of the package. Yes, both packages are using the unexported make_tuple function, but that is the only way to make those packages work. Both packages have a lot of users, so this would cause lots of pain for lots of folks if this gets merged right now.

I did put everything in place so that a NamedTuples v4.0.0 with these changes would not cause any trouble downstream. If you don't want to increase this to v4.0.0 I would have to change all of these limits again so that things don't break. Happy to do that, but not sure I'll be able to fit that in tomorrow, so that might take longer.

[shashi]

I did put everything in place so that a NamedTuples v4.0.0

Ah I see. Then it might be easy to just tag v4.0.0 here

The only valid reason (IMHO :-P) to tag a major / minor release is if you're going to then fix up the old code with patch releases, this doesn't seem like the case here.

[davidanthoff]

We've had a lot of patch releases with NamedTuples, including for old versions (e.g. v2.1.0).

I also second the attobot idea. Also, might it make sense to give some other folks commit access to the repository so that we can speed up things like tagging releases etc? @mdcfrancis?

[tkelman]

It's better to leave too much space for retroactive patch releases than to leave too little space. Since the change in return type (even if the method was not exported) did cause noticeable problems downstream, it could be potentially valuable down the line to do a patch release that fixed some other bug but left in place the old return type behavior. Not saying that's needed right now, but it might be at some future time.

Would it be worth moving this package to an organization, such as JuliaCollections ?

[shashi]

One way to not need the version upper bound is to just use eval(:(@NT(x,y,z))) where you were using make_tuple([:x,:y,:z]) this seems more future proof anyway.

[davidanthoff]

Bump. @mdcfrancis could you rename the v3.0.4 tag to v4.0.0 and leave the v3.0.3 tag as is?

Also, any chance you could give either @shashi or me commit access to NamedTuples.jl, so that we can move faster with situations like this?

[shashi]

I think v4.0.0 should also include JuliaData/NamedTuples.jl#36 and JuliaData/NamedTuples.jl#37

[mdcfrancis]

I have reverted the v3.0.4 tag and will push a new v4.0.0 with the 3.0.4 code and the other two pull requests. Sorry for the delay.

[tkelman]

closing in favor of #9753 then

[mdcfrancis]

Per the thread above we need the v3.0.3 tag that is in this, this merge request had two versions originally