PIG 23 - Gammapy Release Cycle and Version Numbering

[registerrier]

Description

This pull request introduces a PIG on the release scheme and development workflow after v1.0

For now it is a first draft.

Dear reviewer

[codecov]

Codecov Report

Merging #3950 (5d96871) into master (89f67e3) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3950      +/-   ##
==========================================
- Coverage   94.05%   94.04%   -0.02%     
==========================================
  Files         162      162              
  Lines       21402    21438      +36     
==========================================
+ Hits        20130    20161      +31     
- Misses       1272     1277       +5     

Impacted Files	Coverage Δ
gammapy/modeling/iminuit.py	92.52% <0.00%> (-1.87%)	⬇️
gammapy/maps/wcs/ndmap.py	91.12% <0.00%> (-0.44%)	⬇️
gammapy/maps/hpx/ndmap.py	92.45% <0.00%> (-0.41%)	⬇️
gammapy/data/obs_table.py	91.45% <0.00%> (-0.29%)	⬇️
gammapy/modeling/models/temporal.py	99.05% <0.00%> (-0.01%)	⬇️
gammapy/maps/wcs/geom.py	96.49% <0.00%> (ø)
gammapy/estimators/points/lightcurve.py	100.00% <0.00%> (ø)
gammapy/datasets/map.py	93.56% <0.00%> (+0.02%)	⬆️
gammapy/maps/region/ndmap.py	93.37% <0.00%> (+0.04%)	⬆️
gammapy/maps/core.py	86.55% <0.00%> (+0.07%)	⬆️
... and 6 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[AtreyeeS]

Thanks @registerrier !

• When and how do we decide to move from 1.x to 2.0? Probably that will not happen at least in the next 2 yrs, so we have some time to think?
• I suppose that we will have situations where the same bug fix implementation cannot be applied between 1.0.y and 1.x.y because there can be API changes. So the PRs have to be adjusted accordingly?
• I do not know if we are sufficiently well-planned yet to propose deprecation warnings. Maybe we can try putting it, but not make it necessary by adding in the PIG?

[registerrier]

• I suppose that we will have situations where the same bug fix implementation cannot be applied between 1.0.y and 1.x.y because there can be API changes. So the PRs have to be adjusted accordingly?

Good question. I have left a question in the text, but this might not need to be explained in the PIG.
Any idea @adonath ?

• I do not know if we are sufficiently well-planned yet to propose deprecation warnings. Maybe we can try putting it, but not make it necessary by adding in the PIG?

After the co-working week close out meeting we decided to include them.

[registerrier]

This is now ready for review. Please comment! @adonath @AtreyeeS @QRemy @bkhelifi @fabiopintore @LauraOlivera @cosimoNigro and all.

[AtreyeeS]

Thanks @registerrier ! No further comments from my side

[contrera]

Hi
My 2 cents.
I have read the PIG and can´t see any obvious flaw or case when this should not work, but I have little experience in managing large packages on long time scales.
It looks more difficult to handle than before, for the developers, but better for users.

José Luis

[bkhelifi]

Thanks @registerrier. This PIG can be merged.