Development - punctuated and continuous

Some institutions have the resources and needs to engage with Hydra on a continuous basis.  Others can only engage with it periodically.  In this latter case, when they go back they are likely to find that upgrades have broken a lot of the code and that will need to be fixed.  Can we improve on this situation?

Apache creates stable plateaux with defined, documented and tested upgrade paths from one to the next.  Hydra needs a bigger window of stability with stable APIs?

Should we lave a "latest stable" (including necessary bugfixes) and a "leading edge" version?  There will always be a cost to upgrading.  Every year we say that the next major release will be stable - it hasn't happened yet!

The problem of intermittent upgrades will get worse if we start having people adopting solutions as "turnkey" - maybe DIL or Avalon.

Will Hydra 5 be the plateau?  Maybe.

How do we guide people through upgrades?  At the moment, someone tries it and posts their experience to Hydra-tech.  We need a process for documenting problems and solutions.  Currently there is no coordinated approach to this.

We need to make the process of upgrades smoother using better APIs and having a clear view of what they do and do not do.

Moving from Hydra 3 to Hydra 4, or H4 to H5 we have provided warnings of moved and deprecated code.  There is no point trying to do this retrospectively from H2 to H3 - that particular jump merits a 'start again' approach.  Ideally (!) we would like the WordPress single click upgrade experience.

Hydra heads should support turnkey adopters, but people using the framework should expect to recode things from time to time?  As more people build heads and share them, how do we support those who copy and then build off them?

We do get RCs tested before they are released but the process needs to be predictable and manageable.

No decisions made, but a lot of thinking provoked...