Tagging more frequent patch releases?

[SylvainCorlay]

Hey, would you consider tagging releases more frequently, with a patch number (0.6.1, 0.6.2).

• This would help us engage with upstream development: indeed, with the current release cycle, our merged PRs get into releases several months later, so we cannot not use them in our projects. It would be more of an incentive if we new there could be a patch release including our changes in the next few weeks! Also, the 0.5 to 0.6 migration was difficult for us because of the large number of changes at once.
• Also, this may prevent breakages by enabling more rapid feedback from downstream...
• Finally, this would enable rolling out features faster to outside users. For example, we are really excited by the ability to override variable is really cool, but we don't know when it will be in a release!

[SimeonEhrig]

We would also be happy if there are some patch releases. It would make it easier to distribute bug fixes and new features of the CUDA extension. We are also working on an (experimental) integration of the CUDA extension into Xeus-Cling and it is a showstopper for official integration that the cling base is only slowly being updated.

[Axel-Naumann]

Simeon:

it is a showstopper for official integration that the cling base is only slowly being updated

Would this be helped by more frequent patch release tags? I suspect not, unless I misunderstand something?

Sylvain:

consider tagging releases more frequently

In the end that's largely your call: we have (super...) limited dev time for cling, as you probably know it's basically a bit of Vassil and a bit of me. I wish our environment would invest more in the core infrastructure that drives serialization of our 1EB of data, the dynamic python bindings, etc. As it is now all we can do is re-distribute our scarce time, and if you believe tagging is more important than working on issues and PRs then we can certainly increase its priority: tag more often, at the cost of even lower PR and issue resolution throughput.

Sylvain: if you are blocked by too slow progress on our side I'd be happy to discuss inclusion of you / whomever in the core dev team, to allow you to merge PRs, tag etc. I'm not saying you should feel obliged, but you shouldn't exclude that option either. To reduce the impact on high energy physics, we (ROOT) could simply operate off a "slower" branch of cling, that merges with (and validates) cling's main branch from time to time. I'd be happy to adjust infrastructure to whatever helps us get the best out of cling also in the future.

[SylvainCorlay]

In the end that's largely your call: we have (super...) limited dev time for cling, as you probably know it's basically a bit of Vassil and a bit of me. I wish our environment would invest more in the core infrastructure that drives serialization of our 1EB of data, the dynamic python bindings, etc. As it is now all we can do is re-distribute our scarce time, and if you believe tagging is more important than working on issues and PRs then we can certainly increase its priority: tag more often, at the cost of even lower PR and issue resolution throughput.

Hey @Axel-Naumann thanks for responding. I totally undestand the situation as we (at QuantStack) are also severely oversubscribed for the number of open-source package that we maintain and the amount of work to be done.

I was suggesting the adoption of a M.m.p (Major minor patch) versioning schema because it feels to me that tagging releases is really cheap compared to development work, and there can be a high cost to not tagging a release. For example, after the 0.5 tag, there was a number of fixes made that we integrated to the cling conda recipe in the form of patches, because we depended on them in downstream packages. Maintaining such a complex conda recipe with source patches is time consuming.

Also, knowing that there might be a release integrating minor changes sooner may help motivate outside contributors, because they know that they will benefit from the changes that they make.

Sylvain: if you are blocked by too slow progress on our side I'd be happy to discuss inclusion of you / whomever in the core dev team, to allow you to merge PRs, tag etc. I'm not saying you should feel obliged, but you shouldn't exclude that option either.

That may be interesting! Although committing time may be difficult for us.

To reduce the impact on high energy physics, we (ROOT) could simply operate off a "slower" branch of cling, that merges with (and validates) cling's main branch from time to time

It turns out that ROOT is generally using a more recent commit of cling than the latest release so it is not necessarily "slower"!

[SimeonEhrig]

Thanks for the quick answer. You're right, my comment was not well thought out. It's true that anything that helps Sylvain with Xeus-Cling also helps us, because the Xeus-Cling package is a really good way to distribute the entire Jupyter Cling stack. But I also know that your resources are really limited and should be used wisely. But Sylvain is right, without GitHub tags it's not easy to write packages (I know it from spack). Maybe we can find a solution that is good for both sides.

[SylvainCorlay]

@Axel-Naumann would you consider tagging a 0.6.1 release from roughly the latest state of the master branch?

[Axel-Naumann]

Yup - we first need to get two ROOT releases out of the door and then sync ROOT's clang with cling's clang.git. I.e. not this week, but I'll see we get it done soon-ish. New ROOT releases are a good sync point :-)

[SylvainCorlay]

Great! I will stay tuned.

[SylvainCorlay]

Would it make sense for us to play with the __internal-root-e4f16a49508ef80df6349a04530fcc7d04226559 as the next patch release?

[SylvainCorlay]

Hey, I am following up on this. Is there any blocker in tagging the current state of master as 0.6.1?

[Axel-Naumann]

Yes, and that's the reason why it has not happened yet: we need to sync patches from ROOT's repo into clang.git, and we need to fix a failing test in cling. I expect that the former fixes the latter, but both needs to happen before we can tag. (And I'm looking forward to a holiday break first...) It's still on my list!

[SylvainCorlay]

Thanks @Axel-Naumann. I am sorry for nagging! We can't wait to enable variable re-definition in cling.

[Axel-Naumann]

It's perfectly fine to nag, please continue doing that - I'm terribly sorry for our low throughput in cling...

[SylvainCorlay]

Hey, is there a remaining blocker to tagging a cling 0.6.1?

[Axel-Naumann]

Almost there:

• [x] test fixed
• [x] fedora32 support added
• [x] missing llvm/clang patches backported from ROOT
• [x] textinput updated.

@vgvassilev offered to help out with the actual release procedure. Vassil: please tag!

[SylvainCorlay]

Yeah!

[SylvainCorlay]

@vgvassilev @Axel-Naumann many many thanks for releasing 0.7! I am super excited about this release.

I think this issue still stands though. It would have been interesting to start numbering releases with a patch version number (0.7.0) to make minor bugfix releases. For example, when packaging v0.7, I came across issue #352 and submitted a fix. We are including that fix as a patch in the conda recipe, but it would be nice to have a 0.7.1 tagged at some point, that incorporate that kind of simple fixes, and does not change the referenced commit of clang.

[vgvassilev]

Sure, we can do that.

[SylvainCorlay]

Hey @vgvassilev would you guys consider tagging a 0.7.1 version as of current master?

I am especially interested because of the fix to #359.

[vgvassilev]

@SylvainCorlay, sure, I can do that. Please remind me in a week if I have not done it.

[vgvassilev]

@SylvainCorlay v0.8 was tagged!

[SylvainCorlay]

@vgvassilev this is great news!

I don't see the tag on GitHub yet. Does it still have to be pushed?