COmanage Users List

[Bas Zoetekouw <>]

Hi Benn,

> One of the issues we've been thinking about within the project is our
> release cadence. Our last feature release was 10 months ago (v3.1.0,
> back in February, with two release candidates in January), and before
> that v2.0.0 was released in April 2017. (v3.0.0 was released in
> September 2017, but was mostly a UI refresh.) So basically we have a
> slow release cycle with each release having a bundle of new features.
>
> We could consider changing this process. At the opposite end of the
> spectrum, we could cut a release for each new feature. Or perhaps as a
> middle ground, we could schedule (say) quarterly releases, and then
> whatever is ready (which could be nothing) gets included in that
> release. Regardless, we would continue with bug fix releases as needed
> for issues affecting production instances, or for security issues.
>
> If we were to switch to a faster model, we'd release v3.2.0 ASAP (in
> spite of the large number of issues flagged for this release), most
> likely before the end of November. We'd then begin the accelerated
> cycle after that.
>
> So some questions for the community...
>
> - Has the slow release cycle been problematic for you as a deployer?
> -- If not, why not? (eg: You are comfortable running from develop; you
> are in no rush to get new features; etc.)

Yes, we have definitely been hampered by the slow cycle; it seems the
way we are using COmanage is somewhat new, so we would prefer to be able
to get new features quicker.  In particular, there are a number of
features in the 3.2 release we are eagerly awaiting, an we would love a
quick release.

> - If you would prefer a faster release cycle, would you be more
> inclined to update to each release, or just to those with features or
> fixes you were interested in?

We would probably follow the releases as they are. 

That having said, it of course depends on how you define a "release". 
For us, it would probably suffice if you could separate real feature
development to separate branches, and keep the master (or "release")
branch somewhat stable.  We could then simply track the release branch
and be up to date with any new features and fixes, even without you
making an official release.

Regards,
Bas.