4.0 tag

[Zaharid]

While as discussed today I find unrealistic to run all the fits with the same version of the code, we should probably call something the 4.0.XXX version. We should probably decide how that should look like, in particular with view of publishing the code.

This https://www.python.org/dev/peps/pep-0440/ appears (? conda/conda-build#3711) to be the relevant standard for versions although I remember conda having problems with the ordering many years ago...

A simple option would be to tag 4.0(.something?) at the very end and claim that that version would be good to reproduce any fit we present (which really should be the case regardless of how we call it). It would also be a good idea to have some other tag ~next week so it's easy to keep tack of more or less which version of the code production fits were launched.

[scarlehoff]

Yes, you are right. If the code is to be made public having versions will be important. I would add behind the "rcX" and only release a true 4.0(.0) with the paper.

[Zaharid]

There is the question of how each commit version should look like. Do we want to call them "devXX"? If I remember correctly I tried to do this but it was too broken at the time.

[Zaharid]

Tentatively I'll tag as 4.0.0b the merge commit for #1057 (assuming we have no other blockers).

[scarlehoff]

I guess you mean #1057? But yes, I'm happy with that, if #1025 if merged as well even better (so that from now on the reference is a tagged version)

[scarlehoff]

Given that we are (in theory) already running with the final candidate, I think we should tag as 4.0.0rc1 or whatever the commit used for the current candidate.

[wilsonmr]

I suppose with #1126 in mind, were all of the fits for the paper ran with the same environment? I guess there might be small discrepancies but we should probably export that environment asap as well.

[scarlehoff]

I suppose with #1126 in mind, were all of the fits for the paper ran with the same environment? I guess there might be small discrepancies but we should probably export that environment asap as well.

Nop. But for the paper I think we should redo the fits that are going to be released as PDF sets (even if nothing changed at all) all of them with the same environment/tag/etc.

[Zaharid]

I have pushed https://github.com/NNPDF/nnpdf/releases/tag/4.0.0rc with the current master

[Zaharid]

Ok, I am unable to get the rc thing to install properly. So unless somebody objects, I am just going to call it 4.0.

[wilsonmr]

btw despite me agreeing to this, I don't want this exact version for the closure fits because I want the pseudodata dumping in #1081 - does this policy include closure fits?

The exact candidate fits would not be completely reproducible with that PR but as the fit bot shows, they should be very close..

[scarlehoff]

We can wait for the paper tag until we merge #1081.

[Zaharid]

I guess there are several things:

• Do we have a "4.0" tag as per Have a fixed environment for paper #1126 or it doesn't matter what is it called?
• Does the policy of fixed dependencies apply to the nnpdf package itself?
• Do we want to do this as a matter of priority or there are no more fits?

[enocera]

Concerning the third point, I think that an iteration of the nuclear corrections is advised. I'd possibly wait for this iteration (which implies the implementation of modified versions of the dataset systematics, a PR and a review) before we proceed with the tag.