GammaLib

I don’t have concrete thoughts yet on what should be the goal for GammaLib / ctools 1.0, but here are some thoughts.

• I would be in favour of having several small releases (0.9, 0.10, 0.11, ...) over the coming months before the big 1.0 release.

Only with a release do people notice and try out new functionality, which is vital for feedback on the API and real-world testing.
E.g. I don’t know what new background modeling was implemented by the other guys at the coding sprint and a minor release with a “What’s new” document (see http://docs.astropy.org/en/stable/whatsnew/0.3.html for an example) would tell me and get me to try it out.

Serious bug fixes like https://cta-redmine.irap.omp.eu/issues/1004#note-12 warrant a bugfix release to make people aware. All usage / testing is meaningless if running a version that still contains a serious bug.

• A clean API, good test coverage, good documentation and nice features are all important for GammaLib / ctools 1.0. I think setting a preliminary deadline now (e.g. July 2014) and creating a wiki page summarising the most important goals and remaining tasks would be very helpful.

But GammaLib 1.0 will not be perfect and I would not highlight post-1.0 long-term API stability too much. GammaLib will be used for many years by many gamma-ray astronomers for simulations and analysis, and I think that any API improvements that are made in the next few years will pay off in the long-term (say over the next decade or two). E.g. we know that the CTA IRF lookup code with all the hardcoded parameters will most likely not be flexible enough to support the final CTA IRFs. And I presume that when we try to link against external optimisation or SED modelisation packages we will notice that the current API could be improved. So I would recommend to keep GammaLib 1.x stable but after the release allow backwards-incompatible API changes in devel that then lead to GammaLib 2.0 a year or two later.

Deil Christoph wrote:

I don’t have concrete thoughts yet on what should be the goal for GammaLib / ctools 1.0, but here are some thoughts.

• I would be in favour of having several small releases (0.9, 0.10, 0.11, ...) over the coming months before the big 1.0 release.

Only with a release do people notice and try out new functionality, which is vital for feedback on the API and real-world testing.
E.g. I don’t know what new background modeling was implemented by the other guys at the coding sprint and a minor release with a “What’s new” document (see http://docs.astropy.org/en/stable/whatsnew/0.3.html for an example) would tell me and get me to try it out.

Serious bug fixes like https://cta-redmine.irap.omp.eu/issues/1004#note-12 warrant a bugfix release to make people aware. All usage / testing is meaningless if running a version that still contains a serious bug.

My idea was indeed to get a new release out every month, most of these release being in fact bug fix releases. 0.8.1 came out in less than a month from 0.8.0, there is already a new release 0.8.2 that contains a good number of fixes, which could be released soon. I think a frequency of one release per month is reasonable. My feeling is that more frequent releases would probably distract to much the people actually using the tools for their work.

• A clean API, good test coverage, good documentation and nice features are all important for GammaLib / ctools 1.0. I think setting a preliminary deadline now (e.g. July 2014) and creating a wiki page summarising the most important goals and remaining tasks would be very helpful.

Agree.

But GammaLib 1.0 will not be perfect and I would not highlight post-1.0 long-term API stability too much. GammaLib will be used for many years by many gamma-ray astronomers for simulations and analysis, and I think that any API improvements that are made in the next few years will pay off in the long-term (say over the next decade or two). E.g. we know that the CTA IRF lookup code with all the hardcoded parameters will most likely not be flexible enough to support the final CTA IRFs. And I presume that when we try to link against external optimisation or SED modelisation packages we will notice that the current API could be improved. So I would recommend to keep GammaLib 1.x stable but after the release allow backwards-incompatible API changes in devel that then lead to GammaLib 2.0 a year or two later.

I guess we still need to understand better what "stable" in fact means. From my past experience I would guess that the interface will always evolve somewhat. These evolutions can be of various kinds:

• addition of methods: should not be a problem for backward compatibility
• adding of arguments or changing the argument type for existing methods: needs recompilation, can have a very modest impact
• changing of method and class organisation: needs recompilation and may have a substantial impact on existing code

So my feeling is that “stable” means basically that code / interface changes will have only a small or negligible impact on ctools and 3rd party developments.

Jürgen, could you write a ~ 1 page ROADMAP document so that we have a basis for further discussion?

I think having this before the May 12th SeeVogh would be helpful to get an overview of what the most important things are that we should focus on in the coming months...