Roadmap towards GammaLib release 1.0.0

Added by Knödlseder Jürgen about 10 years ago

Christoph has pointed out that it would be good to define the roadmap towards the first stable release of GammaLib, i.e. GammaLib 1.0.0. An example how such a roadmap could look like can be found at https://github.com/rgommers/scipy/blob/roadmap/doc/ROADMAP.rst.txt.

The initial idea I had in mind for GammaLib 1.0.0 was to have a stabilized interface. I invested already quite some time to make the methods more homogenous among the classes, and the result of this effort was release 0.8.0. I then had planned to use release 0.9.0 for additional adjustments that come up in the meantime, so that the subsequent release 1.0.0 could be considered as stable. From that point on, we should try to not change the interfaces too often, to make the ctools development and other 3rd party developments less dependent on evolutions of GammaLib. But it’s not fully clear to me whether this is an idealistic view, or whether this can indeed be realized.

There may be other approaches in term of features, or test coverage, or anything else that could be used as milestone for the release 1.0.0.

In any case, I think it would be good to get this release pretty soon, best within the next 6 months, worst before the end of this year. We could also skip release 0.9.0 if we feel that we can move immediately to a stable release. The idea would then also that release 1.0.0 is the basis for the paper we discussed about during the 2nd ctools coding sprint.

So please go ahead and provide your comments and ideas on this issue.


Replies (3)

RE: Roadmap towards GammaLib release 1.0.0 - Added by Deil Christoph about 10 years ago

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.

RE: Roadmap towards GammaLib release 1.0.0 - Added by Knödlseder Jürgen about 10 years ago

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.

RE: Roadmap towards GammaLib release 1.0.0 - Added by Deil Christoph almost 10 years ago

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...

(1-3/3)